Error when trying to load a Perl Module

[StarGeek]

Occasionally I try to use a perl module not included in the exiftool executable.  Sometimes it works fine but sometimes I'll get an error and the module can't load.

To get access to the modules, I've added this line at the start of my .exiftool_config:
BEGIN{ push @INC, 'C:\Strawberry\perl\lib'; push @INC, 'C:\Strawberry\perl\site\lib';}

Here's an example of the error I got when I tried to add use Unicode::Normalize; (line feeds added for readability)

Code Select Expand

Can't locate loadable object for module Unicode::Normalize in @INC (@INC contains: . C:\Programs\UnixUtils/lib
C:\Users\Bryan\AppData\Local\Temp\par-427279616e\cache-exiftool-10.67\inc\lib
C:\Users\Bryan\AppData\Local\Temp\par-427279616e\cache-exiftool-10.67\inc CODE(0x56bb704) CODE(0x56bb8fc)
C:\Strawberry\perl\lib C:\Strawberry\perl\site\lib) at C:/Perl/site/lib/PAR/Heavy.pm line 96.

There is no "C:/Perl" directory on my system, but all other paths are correct.  Perl -ver returns "This is perl 5, version 26, subversion 1 (v5.26.1) built for MSWin32-x86-multi-thread-64int".  I tried both ActivePerl and Strawberry, and I'm pretty sure I tried both 32 and 64 bit of each.  I know I tried 32 bit of at least one of them.

Any thoughts as to if this can be worked around?  It's not a big deal because if I really need to use the module I can always use the perl version and these are usually extreme cases to begin with.

[Phil Harvey]

Try printing @INC when you run a normal Perl script.  There may be some other directories that need adding.  Where exactly is Unicode::Normalize located?

- Phil

[Hayo Baan]

Do you really have that Unicode::Normalize package in the perl paths?
(my guess is that the reference to c:/perl you see is a "built in the perl executable" path)

[StarGeek]

Output of @INC

Code Select Expand

C:\>perl -e "print join("""\n""",@INC);"
C:/Strawberry/perl/site/lib/MSWin32-x86-multi-thread-64int
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib

Normalize is at "C:\Strawberry\perl\lib\auto\Unicode\Normalize" and I'm able to run it with a the perl version of exiftool like this:
perl exiftool.pl -api "filter=use Unicode::Normalize; $_= NFKD( $_ ); $_=~ s/\p{NonspacingMark}//g;" -TagsFromFile @ -all:all DIR
(no idea what I did there, just me copy/pasting from one StackExchange answer to help another)

I should have mentioned that there is a difference between the Heavy.pm (243 lines) extracted by exiftool executable and the Heavy.pm (254 lines) in "C:\Strawberry\perl\lib\Exporter". 

Code Select Expand

C:\>C:\Programs\UnixUtils\wbin\diff.exe C:\Users\Bryan\AppData\Local\Temp\par-427279616e\cache-exiftool-10.67\inc\lib\Exporter\Heavy.pm "C:\Strawberry\perl\lib\Exporter\Heavy.pm" |clip
1d0
< #line 1 "Exporter/Heavy.pm"
10c9,21
< #line 22
---
> =head1 NAME
>
> Exporter::Heavy - Exporter guts
>
> =head1 SYNOPSIS
>
> (internal use only)
>
> =head1 DESCRIPTION
>
> No user-serviceable parts inside.
>
> =cut

[Phil Harvey]

Hmmm.  I don't know what the problem could be then.  Perhaps something about the autoloaded modules vs PAR.

The difference in Heavy.pm is simply the documentation that PAR deletes from its package file, and shouldn't be a problem.

- Phil

[StarGeek]

No worries then.  I can work around if need be.

No clue why I stuck this thread in Newbies, moving it to Application where I though I started it.

[StarGeek]

I think I know the problem now.  I came across this PAR faq answer and I think that it won't load .dll files that aren't included in the original PAR.  So far, with limited testing (about 4 modules), the ones that won't load all have .dll files.

[Phil Harvey]

But this answer says it will load a .dll (lower case) but not a .DLL (upper case).

- Phil

[StarGeek]

Sorry for not being more clear.  That answer was part of what got me to thinking about the problem.

While I haven't looked into the PAR packer process, that answer made me think that the .dlls needed get wrapped up and included in the executable, correct?  And that made me recall that while I was trying to get Unicode::Normalize to work, I was poking around in its lib directory structure and under both Strawberry and Active Perl, it was a .dll file.  I went back and checked a couple of other modules that I had problems trying to include and they were .dll files as well.  The modules that were only .pm were the ones that worked fine.

It's only anecdotal evidence so far.  Hopefully I'll have time to look deeper at some point.

[Phil Harvey]

Ah.  I see.  DLL's shouldn't need to all be wrapped in the executable (eg. I can write a program that uses system DLL's), but the mechanism for searching for DLL's is different than for Perl modules, which may be causing this problem.

- Phil