How do you generate the exiftool executables?

[Martin B.]

Hi Phil,

How do you generate the executables that you make available for exiftool?
On my Windows system, it doesn't look like a PAR file; it looks like a regular .exe file.

I want to make available a Perl script I wrote that uses Image::ExifTool (and other Perl packages), and your executable works flawlessly, so I thought it'd be good to use the same method. Plus, I'd like to make it available on systems other than Windows.

Thanks,

Martin

[StarGeek]

See this post for a starting point.  You should also come across a discussion between Phil and Oliver @obetz which lead to the alternative exiftool build.

[Martin B.]

Thanks StarGeek.

I was wrong; my ExifTool is from ActivePerl 5.36, not from Phil. That's why it's not a PAR file. Phil's version 12.76 is a PAR file, probably generated from an older version of ActivePerl, which probably explains some minor warnings I get with Unicode file names.

ActivePerl 5.36's PAR doesn't work well with the dynamic loader. I've reported the problem to them, and they said they'd look into it. I was hoping to find an alternate solution in the meantime.

Oliver Betz's solution seems not to be a PAR file either. I'll look into that.

[StarGeek]

Phil's version 12.76 is a PAR file, probably generated from an older version of ActivePerl, which probably explains some minor warnings I get with Unicode file names.

Phil mentions the version somewhere on these forums and if I recall, it is an older version.

Oliver Betz's solution seems not to be a PAR file either. I'll look into that.

Yes, but I was assuming that the conversation would be helpful.  See this thread.

[Martin B.]

Thanks!

[obetz]

I want to make available a Perl script I wrote that uses Image::ExifTool (and other Perl packages)

Have a look at https://oliverbetz.de/pages/Artikel/Portable-Perl-Applications why I dislike PAR and why I suggest to use a clean portable Perl with a tiny launcher instead.

https://oliverbetz.de/pages/Artikel/ExifTool-for-Windows is my package of Strawberry Perl with Phil's ExifTool. You can simply merge your application with the archive.

You can also make a custom launcher from my sources.

[Martin B.]

Thanks Oliver.

Reading your instructions, specifically unpar.txt, I believe I need to have a working PAR file to start with. Am I right?

If so, my problem remains: I use ActivePerl, and their recent versions don't generate a working PAR file when some dynamically loaded module are required (XML::LibXML doesn't work, but Text::CSV_XS does). I suspect this is because ActiveState uses intermediate executables to set environment variables (i.e. ...\Perl\exec\perl.exe defines environment variables pointing to specific version folders before calling ...\Perl\bin\perl.exe), preventing PAR from finding all the required .dll. As I mentioned before, I filed a report and ActiveState said they'd look into it. They've been pretty responsive in the past, so I'm hopeful.

If ActiveState doesn't find a solution, I think my only free choice will be to move to Strawberry Perl. However, that takes me further away from making my stuff available on MacOS as well.

[Phil Harvey]

If it helps: When building a PAR package, you can force a module to be included using the pp -M option.

- Phil

[Martin B.]

Thanks, I know.

The module is included; the problem is some dlls are missing. XML::LibXML is a Perl interface to libxml2, which requires loading several dlls. Looking at the PAR file, I see some dlls, but I think some are missing. It's too tedious for me to debug because pp anonymizes the files it packs, AND libxml's messages are notoriously misleading about the names of the missing dlls. I admit I haven't fully looked into ways of forcing inclusion of dlls (pp -a -A); perhaps that would work.

For what it's worth, the same steps with the same script work with ActivePerl 5.26, but not 5.36. After version 5.28, ActiveState introduced the state tool to maintain packages (it replaces PPM in this regard), create runtimes, manage virtual environments, etc. But in order to do that, some indirection is required and I think that's the issue. I'm not too keen on this indirection scheme, but I like the ease of package maintenance, their versions are up to date, they're giving me support, and I'm using the free version. I don't complain and I try to give back to the community 

[obetz]

Reading your instructions, specifically unpar.txt, I believe I need to have a working PAR file to start with. Am I right?

did you read the last two lines in unpar.txt referring to https://github.com/ChordPro/chordpro/blob/dev/pp/pp2ppl.pl ?

If so, my problem remains: I use ActivePerl,

I have already ruled out ActivePerl for myself since many years because of the "new" license conditions. I'm not sure under what conditions I'm allowed to use it for free, let alone distribute a package built with it.

I also have the impression that Strawberry Perl is better maintained.

and their recent versions don't generate a working PAR file when some dynamically loaded module are required (XML::LibXML doesn't work, but Text::CSV_XS does). I

Setting up a minimal environment (Perl + libs) is indeed quite a lot of work, especially the verification. That's why I only do it rarely (less than once a year).

You can copy the needed files (dll, Perl) manually to the runtime environment.

Has your application more dependencies than included in my package?

[Martin B.]

Quote from: Martin B. on February 16, 2024, 09:42:15 AM
    Reading your instructions, specifically unpar.txt, I believe I need to have a working PAR file to start with. Am I right?
did you read the last two lines in unpar.txt referring to https://github.com/ChordPro/chordpro/blob/dev/pp/pp2ppl.pl ?

Yes, and I understood that pp2ppl.pl is an unpacker. However, I believe my problem is that some files are not included in the package created by pp, so it's a problem with the packer, not the unpacker.

because of the "new" license conditions. I'm not sure under what conditions I'm allowed to use [ActivePerl] for free, let alone distribute a package built with it.

I also have the impression that Strawberry Perl is better maintained.

Yes, I'm concerned about the licensing terms as well. The ActiveState pricing page does mention "Individual users can freely create, install, work with and deploy to production any of the open source language environments offered by the ActiveState Platform with a maximum of 2 developers.", but I intend to ask them if "deploy to production" includes "distribute my open-source PAR file for free".

On the maintenance aspect, I've never used Strawberry Perl, but the versions available from ActiveState are more up-to-date (for instance, they provide the latest ExifTool production version within days of release), and ActiveState's business model is to provide verifiable builds and processes, so they have to be doing something right. But that's beyond today's discussion.

Has your application more dependencies than included in my package?

I don't know. Given that packages can require other packages, is there a way to find out other than actually trying it?
Also, I have other applications that are not related to ExifTool, so I am looking for a generic solution. Again, that's beyond today's discussion

[obetz]

Given that packages can require other packages, is there a way to find out other than actually trying it?

I'm not sure, maybe it depends on how the Perl program checks for existing packages. Maybe Phil can tell more.

Initially, I put a lot of effort into testing for dependencies, for example I used procmon.exe (Sysinternals Process Monitor) to collect the used files when running ExifTool selftests in a full Perl installation.

Since this procedure didn't yield anything missing, I don't do so anymore and rely just on pp. And Perl itself isn't such dynamic anymore, so updating often doesn't seem to bring much benefit.

Therefore I don't build a new Perl environment very often.

If you are not concerned about size, you can simply use the complete (portable) Perl environment. I guess it's 150MB without the C stuff.

[Phil Harvey]

Given that packages can require other packages, is there a way to find out other than actually trying it?

Just trying it won't help.  In the case of ExifTool for instance, some packages are loaded only for very rare code paths, with very specific input parameters.  PAR tries to determine the necessary packages, but it doesn't get all of them.  It will get all the ones included by a simple "use Module" and "require Module", but it will miss them if you do something like "require $module".

- Phil

[Martin B.]

Thanks, that makes sense, and is probably true of all packing tools that might exist.

[obetz]

In the case of ExifTool for instance, some packages are loaded only for very rare code paths, with very specific input parameters.

As long as you have for each possible package an automated test, I can be sure to provide them all.