Opened 3 months ago

Last modified 6 weeks ago

#70459 assigned defect

exiftool @12.920.0_0+perl5_34: Can't locate Image/ExifTool.pm in @INC

Reported by: e-maryniak (Eric Maryniak) Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: jpmelko, contextnerror
Port: exiftool

Description (last modified by ryandesign (Ryan Carsten Schmidt))

$ exiftool
Can't locate Image/ExifTool.pm in @INC (you may need to install the Image::ExifTool module) (@INC contains: /opt/local/libexec/perl5.34/lib /opt/local/lib/perl5/site_perl/5.36/darwin-thread-multi-2level /opt/local/lib/perl5/site_perl/5.36 /opt/local/lib/perl5/vendor_perl/5.36/darwin-thread-multi-2level /opt/local/lib/perl5/vendor_perl/5.36 /opt/local/lib/perl5/5.36/darwin-thread-multi-2level /opt/local/lib/perl5/5.36) at /opt/local/bin/exiftool line 41.

BEGIN failed--compilation aborted at /opt/local/bin/exiftool line 41.

Info about port named [exiftool]:

exiftool @12.920.0 (perl)
Variants:             perl5_28, perl5_30, perl5_32, [+]perl5_34

Description:          General command line utility to read, write and edit EXIF metadata
Homepage:             https://exiftool.org

Library Dependencies: p5.34-image-exiftool
Platforms:            darwin any
License:              (Artistic-1 or GPL)
Maintainers:          Email: devans@macports.org, GitHub: dbevans
Policy: openmaintainer

Specified port is installed.

  exiftool @12.920.0_0+perl5_34 (active)
$ sudo port diagnose
no problems
$ sudo port selfupdate
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.9.3 installed,
MacPorts base version 2.9.3 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
$ sudo port upgrade outdated
Nothing to upgrade.
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
$

Change History (20)

comment:1 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Owner: set to dbevans
Port: exiftool added
Status: newassigned

I can't reproduce this problem. It works for me.

The p5.34-image-exiftool port that exiftool depends on provides the Image::ExifTool module that it's complaining about.

Is the p5.34-image-exiftool port installed and active? If so, you might try forcibly deactivating and reactivating it.

comment:2 Changed 3 months ago by e-maryniak (Eric Maryniak)

By the way, additional info: I am running macOS Big Sur 11.7.10 (higher not possible for iMac Retina 5K 27 inch Late 2014).
The current Perl version is 5.36, so not 5.34, could that be the problem (see @INC)?

$ perl --version
This is perl 5, version 36, subversion 3 (v5.36.3) built for darwin-thread-multi-2level
$

Ad your suggestion, this did not work, I'm sorry to report:

$ sudo port deactivate p5.34-image-exiftool
Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.
The following ports will break: exiftool @12.920.0_0
Continue? [y/N]: y
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Deactivating p5.34-image-exiftool @12.920.0_0
--->  Cleaning p5.34-image-exiftool

$ sudo port activate p5.34-image-exiftool
--->  Computing dependencies for p5.34-image-exiftool
--->  Activating p5.34-image-exiftool @12.920.0_0
--->  Cleaning p5.34-image-exiftool

$ exiftool
Can't locate Image/ExifTool.pm in @INC (you may need to install the Image::ExifTool module) (@INC contains: /opt/local/libexec/perl5.34/lib /opt/local/lib/perl5/site_perl/5.36/darwin-thread-multi-2level /opt/local/lib/perl5/site_perl/5.36 /opt/local/lib/perl5/vendor_perl/5.36/darwin-thread-multi-2level /opt/local/lib/perl5/vendor_perl/5.36 /opt/local/lib/perl5/5.36/darwin-thread-multi-2level /opt/local/lib/perl5/5.36) at /opt/local/bin/exiftool line 41.
BEGIN failed--compilation aborted at /opt/local/bin/exiftool line 41.

$ type -a exiftool
exiftool is /opt/local/bin/exiftool

$ ls -l /opt/local/bin/exiftool
lrwxr-xr-x 1 root wheel 36 Jul 26 07:53 /opt/local/bin/exiftool -> /opt/local/libexec/perl5.34/exiftool

$
Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:3 Changed 3 months ago by e-maryniak (Eric Maryniak)

Ah, I think I see what the problem might be: /opt/local/lib/perl5/vendor_perl/5.34 is not in @INC. Note:

$ find /opt/local/libexec /opt/local/lib -iname 'exiftool*' -print
/opt/local/libexec/perl5.34/exiftool
/opt/local/lib/perl5/vendor_perl/5.34/Image/ExifTool
/opt/local/lib/perl5/vendor_perl/5.34/Image/ExifTool.pod
/opt/local/lib/perl5/vendor_perl/5.34/Image/ExifTool.pm
/opt/local/lib/perl5/vendor_perl/5.34/darwin-thread-multi-2level/auto/Image/ExifTool
$
Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:4 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

I can't explain why it works for me and does not work for you.

I can't explain why your @INC contains both perl 5.34 and perl 5.36 paths.

Hopefully the maintainer of the ports, to whom the ticket is assigned, has some ideas.

Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:5 Changed 3 months ago by e-maryniak (Eric Maryniak)

I see, Ryan, thanks -- I guess my iMac with Big Sur (which is somewhat 'old', of course) is apparently good enough for Perl 5.36 as main package to be installed, but somehow for Exiftool only supported for 5.34 as the ExifTool.pm does not pop up in de vendor path of 5.36.

I guess I might try downgrading the 'main' Perl to 5.34?

comment:6 Changed 3 months ago by e-maryniak (Eric Maryniak)

Well, I found a workaround -- probably very ugly, but it did not break 'exiftool' and the few Perl scripts that I wrote myself.

So, I noticed that directory /opt/local/lib/perl5/vendor_perl only contained subdirectory 5.34 (not 5.36, and remember 'perl --version' gives 5.36). I put a symlink for 5.36 to 5.34 and now 'exiftool' worked:

$ cd /opt/local/lib/perl5/vendor_perl
$ ls -l
total 0
drwxr-xr-x 26 root admin 832 Jul 27 22:54 5.34
$ sudo ln -sv 5.34 5.36
'5.36' -> '5.34'
$ ls -l
total 0
drwxr-xr-x 26 root admin 832 Jul 27 22:54 5.34
lrwxr-xr-x  1 root admin   4 Jul 28 16:33 5.36 -> 5.34
$ exiftool -ver
12.92
$_

comment:7 in reply to:  6 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to e-maryniak:

I guess my iMac with Big Sur (which is somewhat 'old', of course) is apparently good enough for Perl 5.36 as main package to be installed, but somehow for Exiftool only supported for 5.34

That's not specific to your computer or OS version. There are no ports of any module for perl 5.36 yet; nobody has volunteered to create them. See comment:ticket:67830:2.

Replying to e-maryniak:

I put a symlink for 5.36 to 5.34 and now 'exiftool' worked:

You will need to remove that symlink before we add perl 5.36 module ports otherwise you will have problems.

comment:8 Changed 3 months ago by e-maryniak (Eric Maryniak)

Ok, removed the symlink '5.36' in /opt/local/lib/perl5/vendor_perl, thanks for the proactive advise!

Ad your comment:ticket:67830:2: I see it's partly a (hardware) resource issue, i.e. doing bulk compiles of lots of CPAN modules for 5.36 (and 5.38) overload the build system. Well, being a MacPorts nitwit, I'll do my part and donate $$ to the project :-)

In the meantime: I tried another "fix" (probably not the way to do it, either).
I replaced the first line of /opt/local/bin/exiftool from:

#!/usr/bin/env perl5

to:

#!/usr/bin/env perl5.34.3

And now 'exiftool' started OK. Would that be a less dirty fix?
The source of 'exiftool' v12.92 mentions 'require 5.004', so I guess that's ok strictly from the program's point of view?

Last edited 3 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:9 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

I have p5.34-image-exiftool @12.890.0_0 installed, which I realize now is an older version. /opt/local/bin/exiftool is, as you've noted, a symlink to /opt/local/libexec/perl5.34/exiftool, and the first line of that script on my system is:

#!/opt/local/bin/perl5.34 -w

I checked the precompiled archive of @12.890.0_0 on the server and that's what's in there too.

I then checked the precompiled archive of @12.910.0_0 and the first line of the script in that version is:

#!/usr/bin/env perl -w

And in the @12.920.0_0 archive it's:

#!/usr/bin/env perl

which is similar to though not identical to what you reported. The fact that this line is not referencing the correct versioned perl executable is likely the problem, and changing that line as you did is a good workaround until we can figure out how to make the port do that automatically again, although you will want to specify perl5.34 instead; specifying perl5.34.3 will break the moment the perl5.34 port is updated to a new version.

The port updates to those versions did nothing other than update the version and checksums, so the problem was not caused by MacPorts but by an undesirable upstream change.

It's not the same problem, but another bug caused by this change is described here: https://github.com/exiftool/exiftool/issues/273

Per the changelog entry for version 12.90, they Changed exiftool shebang from "#!/usr/bin/perl" to "#!/usr/bin/env perl".

There must be some fixup process that fixed #!/usr/bin/perl to be the perl executable we asked for, and that fixup process does not know to do the same thing to #!/usr/bin/env perl. I assumed that fixup would be a reinplace in the perl5 portgroup but I don't see it. It might be done automatically by perl when building a module.

comment:10 in reply to:  4 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to ryandesign:

I can't explain why your @INC contains both perl 5.34 and perl 5.36 paths.

I do see this on my system now as well, after updating p5.34-image-exiftool to the current version. Whether I have perl5 installed with +perl5_36 or +perl5_38 variants, I see /opt/local/libexec/perl5.34/lib in @INC along with the appropriate other paths having 5.36 or 5.38. I still don't know why. The 5.34 path is not present if I run perl5.36 -e "print \"@INC\n\"" or perl5.38 -e "print \"@INC\n\"" so maybe it is a normal artifact of trying to run something built for 5.34 with a different version—which is of course something that should never be done.

comment:11 Changed 3 months ago by e-maryniak (Eric Maryniak)

Thanks for the advise to not use the subversion (.3) but instead:

#!/usr/bin/env perl5.34

Indeed #!/usr/bin/env perl5 is what the current installation of exiftool does:

$ sudo port uninstall exiftool
--->  Deactivating exiftool @12.920.0_0+perl5_34
--->  Cleaning exiftool
--->  Uninstalling exiftool @12.920.0_0+perl5_34
--->  Cleaning exiftool
$ sudo port install exiftool
--->  Computing dependencies for exiftool
--->  Fetching archive for exiftool
--->  Attempting to fetch exiftool-12.920.0_0+perl5_34.darwin_any.noarch.tbz2 from https://packages.macports.org/exiftool
--->  Attempting to fetch exiftool-12.920.0_0+perl5_34.darwin_any.noarch.tbz2.rmd160 from https://packages.macports.org/exiftool
--->  Installing exiftool @12.920.0_0+perl5_34
--->  Activating exiftool @12.920.0_0+perl5_34
--->  Cleaning exiftool
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
$ head -n 1 /opt/local/bin/exiftool 
#!/usr/bin/env perl5
$_

Looking forward to a more permanent solution which, if I understand you well, should not be too difficult (a fixed reinplace or "after-fix-reinplace` when the CPAN build has completed).

Last edited 3 months ago by e-maryniak (Eric Maryniak) (previous) (diff)

comment:12 in reply to:  11 ; Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to e-maryniak:

Indeed #!/usr/bin/env perl5 is what the current installation of exiftool does:

$ sudo port uninstall exiftool
--->  Deactivating exiftool @12.920.0_0+perl5_34
--->  Cleaning exiftool
--->  Uninstalling exiftool @12.920.0_0+perl5_34
--->  Cleaning exiftool
$ sudo port install exiftool
--->  Computing dependencies for exiftool
--->  Fetching archive for exiftool
--->  Attempting to fetch exiftool-12.920.0_0+perl5_34.darwin_any.noarch.tbz2 from https://packages.macports.org/exiftool
--->  Attempting to fetch exiftool-12.920.0_0+perl5_34.darwin_any.noarch.tbz2.rmd160 from https://packages.macports.org/exiftool
--->  Installing exiftool @12.920.0_0+perl5_34
--->  Activating exiftool @12.920.0_0+perl5_34
--->  Cleaning exiftool
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
$ head -n 1 /opt/local/bin/exiftool 
#!/usr/bin/env perl5
$_

Uninstalling and reinstalling the exiftool port doesn't prove anything in that regard since the exiftool port only installs the /opt/local/bin/exiftool symlink. The script it points to, /opt/local/libexec/perl5.34/exiftool, is installed by the p5.34-image-exiftool port. Uninstalling and reinstalling that port would prove what that file contains right after installation.

Looking forward to a more permanent solution which, if I understand you well, should not be too difficult (a fixed reinplace or "after-fix-reinplace` when the CPAN build has completed).

The question is where the fix needs to be and how far the problem extends. The problem seems to have been caused by an innocuous-seeming change of the shebang line by the exiftool authors. If the fixing of the shebang line occurs in the perl module build process, should it have caught the new one too—do we need to file a bug report with the developers of perl or one of its module-building modules? Or if the fix should be in the perl5 portgroup we can of course fix it there. But how many other ports that use the perl5 portgroup or this module building process are also using the "wrong" shebang line that isn't being replaced? How do we identify and fix them all? Or is it perhaps erroneous for the developers of exiftool to have made this change and we should ask them to change it back?

comment:13 Changed 3 months ago by e-maryniak (Eric Maryniak)

I see, well, for now I have a 'fix' -- I'd be happy to test a new release of an exiftool port (alfa or beta) should it become available.
Thanks for all the fish, I mean, help :-)

comment:14 in reply to:  12 Changed 3 months ago by e-maryniak (Eric Maryniak)

Replying to ryandesign:

Replying to e-maryniak:

...

... The question is where the fix needs to be and how far the problem extends. The problem seems to have been caused by an innocuous-seeming change of the shebang line by the exiftool authors. If the fixing of the shebang line occurs in the perl module build process, should it have caught the new one too—do we need to file a bug report with the developers of perl or one of its module-building modules? Or if the fix should be in the perl5 portgroup we can of course fix it there. But how many other ports that use the perl5 portgroup or this module building process are also using the "wrong" shebang line that isn't being replaced? How do we identify and fix them all? Or is it perhaps erroneous for the developers of exiftool to have made this change and we should ask them to change it back?

To be explicit, these were the changes in the ExifTool code (ref https://www.exiftool.org/history.html), all on the same day:

July 24, 2024 - Version 12.92

  • Removed -w from exiftool shebang due to compatibility issues on some systems

July 24, 2024 - Version 12.90

  • Changed exiftool shebang to use env: "#!/usr/bin/env perl -w"
Last edited 3 months ago by e-maryniak (Eric Maryniak) (previous) (diff)

comment:15 Changed 3 months ago by e-maryniak (Eric Maryniak)

Problem still exits with latest (2024-08-22) update of MacPorts version of ExifTool exiftool @12.930.0 (perl) and p5.34-image-exiftool that has #!/usr/bin/env perl as shebang (added some newlines for readability):

Can't locate Image/ExifTool.pm in @INC
(you may need to install the Image::ExifTool module)
(@INC contains:
 /opt/local/libexec/perl5.34/lib
 /opt/local/lib/perl5/site_perl/5.36/darwin-thread-multi-2level
 /opt/local/lib/perl5/site_perl/5.36
 /opt/local/lib/perl5/vendor_perl/5.36/darwin-thread-multi-2level
 /opt/local/lib/perl5/vendor_perl/5.36
 /opt/local/lib/perl5/5.36/darwin-thread-multi-2level
 /opt/local/lib/perl5/5.36)
at /opt/local/bin/exiftool line 41.
BEGIN failed--compilation aborted at /opt/local/bin/exiftool line 41.

comment:16 Changed 2 months ago by jpmelko

Same for me

exiftool                       @12.960.0_0+perl5_34

on catalina

comment:17 Changed 2 months ago by jpmelko

Cc: jpmelko added

comment:18 Changed 6 weeks ago by contextnerror

I am currently experiencing this problem on version 12.970.0 but with different output.

Can't locate Image/ExifTool.pm in @INC (you may need to install the Image::ExifTool module) 
(@INC contains:
 /opt/local/libexec/perl5.34/lib
 /Library/Perl/5.18/darwin-thread-multi-2level
 /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level
 /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.4
 /System/Library/Perl/5.18/darwin-thread-multi-2level
 /System/Library/Perl/5.18
 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level
 /System/Library/Perl/Extras/5.18 .) 
at /opt/local/bin/exiftool line 41.
BEGIN failed--compilation aborted at /opt/local/bin/exiftool line 41.

I am not sure why it is trying to use the system perl.

comment:19 Changed 6 weeks ago by contextnerror

Cc: contextnerror added

comment:20 in reply to:  18 Changed 6 weeks ago by ryandesign (Ryan Carsten Schmidt)

Replying to contextnerror:

I am not sure why it is trying to use the system perl.

#!/usr/bin/env perl means use whatever perl is. On your system, in your terminal, with your path settings, that's the system perl. The solution is to fix the port so that its files do not refer to #!/usr/bin/env perl but instead to the specific version of MacPorts perl that we want it to use, like it did before.

Note: See TracTickets for help on using tickets.