Bravo_t has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I came into this weird issue about finding Perl modules. The problem happens in a script written by others.

A Perl module called SWIG**.pm in put under /some/path/perl/5.8.0/x86_64-linux-thread-multi, and before "use" this module,

use lib "/some/path/perl"

is added. I'm surprised to know Perl will "recursively" add sub directories into @INC if they have some particular names. In this case, "/some/path/perl", "/some/path/perl/5.8.0" and "/some/path/perl/5.8.0/x86_64-linux-thread-multi" will all be added in @INC.

But this is where the issue happens. For some unknown reason, Perl will not add the sub directories into @INC, and the script then report an error: cannot find SWIG**.pm. This issue seems to happen entirely random. I don't when and under what conditions Perl will produce an error like this. The only thing I know is that, when the error happens, both sub directories "/some/path/perl/5.8.0" and "/some/path/perl/5.8.0/x86_64-linux-thread-multi" are missing in the @INC. I want to know if there're any potential reasons that prevent Perl from adding the sub directories into @INC.

Thanks a lot!

-----------------

Update

The dir structure looks like this:

/some/path/perl/5.8.0/x86_64-linux-thread-multi
/some/path/perl/5.8.0/x86_64-linux-thread-multi/.lib
/some/path/perl/5.8.0/x86_64-linux-thread-multi/auto
/some/path/perl/5.8.0/x86_64-linux-thread-multi/auto/SWIG**
/some/path/perl/5.8.0/x86_64-linux-thread-multi/SWIG**/libSWIG**.so
/some/path/perl/5.8.0/x86_64-linux-thread-multi/SWIG**.pm

[download]

All these dirs and files are readable by anyone.

-----------------

Update

Thanks for all of you guys, the problem is now solved. The reason is exactly the one you mentioned, the version of the Perl interpreter. It turns out that, the Perl interpreter on different lsf clusters are different. Even though the shebang of that script is the same, the file that shebang points to is a link, and it links to different Perl interpreters from different lsf cluster's view. I should find someone in the infrastructure department to look at this.

Thank you all, again.

Replies are listed 'Best First'.
Re: Perl randomly couldn't locate a Perl module in @INC
by Athanasius (Archbishop) on Jul 23, 2015 at 07:06 UTC

    Hello Bravo_t, and welcome to the Monastery!

    The behaviour of the lib pragma is documented here.

    I'm surprised to know Perl will "recursively" add sub directories into @INC if they have some particular names.

    Yes, but those names are specific to your current version of Perl. For example, I currently get:

    16:54 >perl -V:archname
archname='MSWin32-x64-multi-thread';

16:54 >perl -V:version
version='5.22.0';

16:54 >

    [download]

    So if I have:

    use lib "./some/path/perl";

    [download]

    and if there is a directory ./some/path/perl/5.22.0 on my system, then my @INC will contain:

    "./some/path/perl/5.22.0",
"./some/path/perl",
...

    [download]

    But if I also have a directory ./some/path/perl/5.8.0, that will not be added to @INC because it doesn’t correspond to the version of my current Perl.

    So, my best guess is that the apparently random behaviour you are seeing is actually due to you calling the script with different versions of the Perl executable.

    Hope that helps,

    Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

[reply]
[d/l]
[select]

      Thanks for your reply and sharing with me the doc.

      I will see if it's caused by the version of Perl interpreter, Thanks.

[reply]
Re: Perl randomly couldn't locate a Perl module in @INC
by Corion (Patriarch) on Jul 23, 2015 at 07:08 UTC

    For example if Perl does not have the appropriate read/execute permissions, it will not add the directories.

    You will have to collect more data on the situations when @INC gets populated and when not. Maybe you are using different Perl interpreters?

    Also, some code and a ls -lR of the relevant directory could be helpful. These directories are not network mounted or on otherwise removable devices, are they?

[reply]
[d/l]

      Thanks for your help.

      But there should be no permission issues because the paths and files are located in my company's folder which are "public" for us. It is also the reason that I didn't give you any detailed info about this, I'm not sure what to share, what not to. I'll update my question to add the info as much as possible.

      Also, I will see if it's an issue of interpreter versions.

      Thanks again.

[reply]
Re: Perl randomly couldn't locate a Perl module in @INC
by MidLifeXis (Monsignor) on Jul 23, 2015 at 12:51 UTC

    In addition to the questions asked above, is '**' actually in the name of the directories / module names / file names?

    --MidLifeXis

[reply]

      No no, of course not. The "**" are just wildcards replacing the self-explanatory file name used by my company.

      Anyway, the problem is now solved, because of the version of Perl interpreter between my local computer and lsf clusters are different. I should find a infrastructure guy to look at this.

      Thank you all for helping me!

[reply]

Back to Seekers of Perl Wisdom