G'day iqbal_1956,

Welcome to the Monastery.

"Attempt to reload Scalar/Util.pm aborted."

See "perldiag: Attempt to reload %s aborted." for more details on that.

"Looks like a standard incompatibility between something."

You're using v5.16.3 and the current version is v5.34.0: there's one possible cause.

Scalar::Util is a core module; these are different: "Scalar::Util (for Perl 5.16.3)" and "Scalar::Util (for Perl 5.34.0)". It's also a CPAN module found in the Scalar-List-Utils distribution. Possibly some conflict there.

If I look at the Depenency graph for Alien::Libxml2, it currently defaults to v5.34.0 which shows no dependency on Scalar::Util or Scalar-List-Utils; if I change the version to v5.16.3 it shows additional dependencies, including Scalar-List-Utils.

"All the mentioned modules have been rebuilt with the latest from metacpan ..."

and later:

"Use of all the standard install tools is not under our control so we need to be able to deploy the packages to a non-root owned location which we have control over."

You don't say how you are achieving that, but it seems fraught with potential problems. How are you handling @INC such that the version of Scalar::Util you installed from CPAN is being used in preference to the core version you already have? Did you need to do anything special with $ENV{PATH}? Have you done non-standard things that we should know about to provide you with better help?

It's never a good idea to mess with the system Perl (regardless of the underlying operating system) and your sysadmins may have very good reasons for restricting access.

Take a look at Perlbrew. This will allow you to install CPAN modules without requiring root access. You can also use it to install multiple versions of Perl and easily switch between them (if that's useful for you). I've been using Perlbrew for over a decade, on a variety of OSes, and can highly recommend it. I believe there are similar solutions available; however, I'm not familiar with them — perhaps other monks could suggest alternatives.

Thank you for the response which is very helpful and enlightening; I did not know of the existence of perlbrew and will file away the new knowledge for use in future meditations. The tool looks like it would be ideal in this situation for what we would like to achieve. However, our problem is that our host is completely locked down and has no direct internet access. I will try it out on a different host under different circumstances in the future though.

Usually it would be easier to use your OS package manager to install libxml2 (and libxml2-dev) instead of Alien::libxml. Maybe you can avoid building it yourself by having your sysadmin install that package?

Thank you for the reply & agreed. Unfortunately we do not have root privileges on the host and will not be given them any time soon. Use of all the standard install tools is not under our control so we need to be able to deploy the packages to a non-root owned location which we have control over.

This is just guesswork, but what happens if you try these steps?

Can Perl can load Scalar::Util?

perl -MScalar::Util -e1
[download]

Are there lib dirs from other perl versions in your path?

perl -MScalar::Util -E'say join q{ }, @INC'
[download]

Yes - this is the problem. That gives this:

perl -MScalar::Util -e1

List::Util object version 1.27 does not match bootstrap parameter 1.56
+ at /usr/lib64/perl5/DynaLoader.pm line 213.
Compilation failed in require at /nfs/home/ ... /perl5/perllib/lib/per
+l5/Scalar/Util.pm line 23.
Compilation failed in require.
BEGIN failed--compilation aborted.
[download]

So it is an incompatibility between the modules we have downloaded from METACPAN and the default distributions which have come on the box. We will need to go with one or the other but not a mix of both. Either way we will need to get the sys admins to either install some more packages (as was initially suggested above) or remove what's there. It's always a pity when there is no direct root acces....

Thank you for the response and guidance. All the suggestions in this chain have been very helpful in uncovering the issue and moving us forward

Installing a separate perl using something like perlbrew is the simplest way to go, as suggested by kcott in 11135780. That assumes you can get past the lack of internet access, although I assume others have encountered and and solved that issue previously so there will be previous experiences you can draw on.

Another option is to use local::lib to keep your module installs out of the way of the system package tree.

Another consideration is how you installed the local modules from metacpan. If you have no direct internet access on that box (as noted in 11135802) then I assume you downloaded the tarballs manually and transferred them across? Did you run the module tests? Did they fail and you then force installed? Did you skip the tests? I would expect the module tests would throw issues in cases like this.

And don't forget to check the value of @INC. It could be that your modules installed correctly, but if .../perl/site/lib is listed after .../perl/lib then issues like this can occur.

/usr/lib64/perl5/ suggests you are using the system perl, and /nfs/home/.../perl5/perllib/lib/perl5 suggests a manually provided addition to @INC. Sounds like this manually added path is garbage (belonds to a different perl).

What's the output of

perl -M5.010 -e'
   say for @INC;
   say "$_: $ENV{$_}" for sort grep /^PERL/, keys(%ENV);
'
[download]

(Best to use a different word rather than ... for private info.)

Seeking work! You can reach me at ikegami@adaelis.com

Do yourself a favor and try Perlbrew. Best regards, Karl

perl -MAlien::Build::MM -e 1

perl -V