Add $SAGE_LOCAL/lib64 to LD_LIBRARY_PATH

[jdemeyer]

This is needed for #12369 (and would probably have provided an easier fix for #12131): I can't convince gcc-4.4.6 to install its libraries in $SAGE_LOCAL/lib, it always uses $SAGE_LOCAL/lib64 on sage.math.washington.edu.

Apply 12405_lib64.patch to SAGE_ROOT.

[vbraun]

lib64 is widely used but no standard. lib32 isn't standard at all, as far as I know only debian variants use it. And they are moving towards multiarch, which will rename these to lib/i386-linux-gnu etc., see  http://wiki.debian.org/Multiarch. So unless you want to add all possible triplets to the LD_LIBRARY_PATH I suggest we rather the gcc package to respect standard configure options.

-1 from me for this proposal.

[jdemeyer]

Replying to vbraun: If we decide to ship a gcc package and this patch works and nobody comes up with a better solution, I guess we have no choice, right?

[jdemeyer]

If you prefer: we could only add existing directories (or some unknown-to-me way of detecting the multilib directories)

[vbraun]

I'll try fixing the gcc package first, this is really the sane way to do. At the very least we need to disable multilib building because not everybody has a multilib toolchain (Fedora doesn't, for example).

[jdemeyer]

Replying to vbraun:

I'll try fixing the gcc package first, this is really the sane way to do. At the very least we need to disable multilib building because not everybody has a multilib toolchain (Fedora doesn't, for example).

Volker, in your GCC spkg, you copy files from lib64 to lib. This suffers from all the problems you mentioned here. It has the additional problem that you need to decide which files you copy.

So I still think changing LD_LIBRARY_PATH is the best solution. But I'm certainly open to suggestions...

[jhpalmieri]

I don't understand any of the subtleties here, but would it make sense to test whether the directory $SAGE_ROOT/local/lib64 exists, and if so, put it first (before local/lib) in $LD_LIBRARY_PATH? If some spkg (like gcc) is the first one to install files in lib64, does $LD_LIBRARY_PATH need to include lib64 while that spkg is being installed, or will it only matter for later spkgs? If only for later ones, well, sage-spkg should run sage-env for each installation, so $LD_LIBRARY_PATH should get set for all subsequent packages.

[jdemeyer]

Replying to jhpalmieri:

I don't understand any of the subtleties here, but would it make sense to test whether the directory $SAGE_ROOT/local/lib64 exists, and if so, put it first (before local/lib) in $LD_LIBRARY_PATH?

Yes, that would make a lot of sense.

If some spkg (like gcc) is the first one to install files in lib64, does $LD_LIBRARY_PATH need to include lib64 while that spkg is being installed

No.

or will it only matter for later spkgs?

Exactly, there might be some subtleties with parallel builds though. But GCC (the package this is about) normally isn't built in parallel with anything else, so it doesn't really matter.

[jhpalmieri]

Replying to jdemeyer:

Exactly, there might be some subtleties with parallel builds though.

Even with parallel builds, if deps is correct, then if two packages are built at the same time, they shouldn't install things in local/lib64 that the other one needs. There could be a race condition in creating local/lib64, I suppose, but that should be avoidable.

[jdemeyer]

I changed the patch to add only existing directories.

[jhpalmieri]

This looks okay to me, but I don't think I'm qualified to review it. vbraun, what do you think?

[vbraun]

I don't think adding more stuff to LD_LIBRARY_PATH is the way to go. On the contrary, we have to get rid of it or we'll always have library conflicts on some systems. Also, this ticket is really just our ignorance about how to make gcc install its libraries in a specified directory. It must be possible since distros can do it.

Having said that, I don't mind if we use this as a bandaid until we figure out how to configure gcc correctly and/or Apple manages to ship a working compiler.

[jdemeyer]

Replying to vbraun:

Having said that, I don't mind if we use this as a bandaid until we figure out how to configure gcc correctly.

Good. As I mentioned above, I am certainly open to suggestions but this is the best "solution" I could think of.

[jhpalmieri]

So can we give it a positive review? I've been using it successfully (via #12369) for a while now, with no problems.

[vbraun]

Lets do it.