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 attachment: 12405_lib64.patch to SAGE_ROOT.

Component: scripts

Author: Jeroen Demeyer

Reviewer: Volker Braun

Merged: sage-5.0.beta8

Issue created by migration from https://trac.sagemath.org/ticket/12405

[jdemeyer]

Description changed:

--- 
+++ 
@@ -1 +1,3 @@
 This is needed for #12369 (and would probably have provided an easier fix for #12131).
+
+**Apply** [attachment: 12405_lib64.patch](https://github.com/sagemath/sage-prod/files/10654686/12405_lib64.patch.gz) to `SAGE_ROOT`.

[jdemeyer]

Description changed:

--- 
+++ 
@@ -1,3 +1,3 @@
-This is needed for #12369 (and would probably have provided an easier fix for #12131).
+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** [attachment: 12405_lib64.patch](https://github.com/sagemath/sage-prod/files/10654686/12405_lib64.patch.gz) to `SAGE_ROOT`.

[vbraun]

comment:3

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]

comment:4

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]

comment:5

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

[vbraun]

comment:6

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]

comment:7

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]

comment:8

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]

comment:9

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]

comment:10

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.