Opened 10 years ago

Closed 10 years ago

#12405 closed enhancement (fixed)

Add $SAGE_LOCAL/lib64 to LD_LIBRARY_PATH

Reported by: jdemeyer Owned by: leif
Priority: major Milestone: sage-5.0
Component: scripts Keywords:
Cc: Merged in: sage-5.0.beta8
Authors: Jeroen Demeyer Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by 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.

Attachments (1)

12405_lib64.patch (1.3 KB) - added by jdemeyer 10 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 10 years ago by jdemeyer

  • Description modified (diff)

comment:2 Changed 10 years ago by jdemeyer

  • Description modified (diff)

comment:3 follow-up: Changed 10 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 10 years ago by 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?

comment:5 Changed 10 years ago by jdemeyer

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

comment:6 follow-up: Changed 10 years ago by 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).

comment:7 in reply to: ↑ 6 Changed 10 years ago by 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...

comment:8 follow-up: Changed 10 years ago by 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.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 10 years ago by 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.

comment:10 in reply to: ↑ 9 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by jdemeyer

  • Status changed from new to needs_review

I changed the patch to add only existing directories.

Changed 10 years ago by jdemeyer

comment:12 Changed 10 years ago by jhpalmieri

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

comment:13 follow-up: Changed 10 years ago by 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.

comment:14 in reply to: ↑ 13 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by jhpalmieri

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

comment:16 Changed 10 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

Lets do it.

comment:17 Changed 10 years ago by jdemeyer

  • Merged in set to sage-5.0.beta8
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.