Re-order $Config{libpth} in DynaLoader in 64bit env

[Tux]

In a 64bit environment, force 64bit locations before 32bit locations.
This will move /usr/lib64 in front of /usr/lib and /lib64 in front of
/lib. This is important if a module uses $Config{libpth} to find a
library to load, like FFI::CheckLib does. If a library is installed in
both locations, it is likely to pick the wrong one if the order is not
showing the correct architecture first
As this clutch only looks at trailing 64, it will have no impact on
locations differing completely, as /usr/lib vs /usr/lib/i386-linux-gnu/
like on debian.

Also just include existing PATH elements and filter duplicates.

[jkeenan]

@Tux, this p.r. was submitted as a draft last May. I have rebased it on blead, thereby resolving merge conflicts. Would you like it to enter code review?

Thank you very much.
Jim Keenan

[Tux]

(still) looks fine to me. I vote +1, but that won't surprise you

[Leont]

This feels like the wrong place to fix this. If the order is wrong, why not fix it in Configure?

[Tux]

@Leont because the development environment on the box where perl was built (and distributed from) might be completely different from the box where this eventually is used. The moment of actual use might have access to many more resource locations than what is done inside Configure, so it needs to be as dynamic as possible and as late as possible.
Every module's Makefile.PL (or wharever is used) may add resource locations, and when you do this in Configure, you cannot fix that anymore

[Leont]

Why are there 32bit and 64bit entries in the same libpth? That doesn't make sense, one can't link to both. Isn't that the real (Configure) issue?

[Tux]

Because not all systems have separated them nicely. /lib and /usr/lib might be 32bit or 64bit (or both in case of AIX). /usr/lib64 (and variations like /usr/lib/hpux64 and /usr/lib/pa20_64) were introduced when *ux started to support both. On AIX a .a will host both 32bit and 64bit (neither of which you can see from the outside without options or environment settings) and on HP-UX, (shared) libs in /usr/lib will/might point to either /usr/lib/hpux32 or /usr/lib/hpux64 (and all variations). There is no rule there.
So when building 64-bit perl, /usr/lib should be included.
Furthermore, building perl might have a diffent content for /lib and /usr/lib than a system where perl will be installed and run, so you will need both when building (additional) XS.

[Leont]

Because not all systems have separated them nicely. /lib and /usr/lib might be 32bit or 64bit (or both in case of AIX). /usr/lib64 (and variations like /usr/lib/hpux64 and /usr/lib/pa20_64) were introduced when *ux started to support both. On AIX a .a will host both 32bit and 64bit (neither of which you can see from the outside without options or environment settings) and on HP-UX, (shared) libs in /usr/lib will/might point to either /usr/lib/hpux32 or /usr/lib/hpux64 (and all variations). There is no rule there.
So when building 64-bit perl, /usr/lib should be included.

This still sounds like a Configure issue. There shouldn't be any paths in libpth that can't be used for finding libraries.

Furthermore, building perl might have a diffent content for /lib and /usr/lib than a system where perl will be installed and run, so you will need both when building (additional) XS.

Franky, this is not a situation that we have ever supported. Maybe we want to support it on some systems, but I don't think we want to force it upon everyone else. Like much of DynaLoader_pm.PL, such code should be optional.

[rjbs]

It's the unanimous opinion of the PSC that this problem is not Perl's to fix, it's effectively an unsupported configuration.