Opened 3 years ago

Closed 3 years ago

#19776 closed defect (fixed)

Globally set -L library search path

Reported by: vbraun Owned by:
Priority: blocker Milestone: sage-7.0
Component: build Keywords: LDFLAGS sage-env
Cc: ncohen, jpflori, fbissey Merged in:
Authors: Volker Braun Reviewers: François Bissey
Report Upstream: N/A Work issues:
Branch: 34cba4c (Commits) Commit: 34cba4c7171e9b3cc77d819cf0082243173dd267
Dependencies: Stopgaps:

Description (last modified by leif)

Add -L$SAGE_LOCAL/lib to LDFLAGS in sage-env


See #19782 for symlinking $SAGE_LOCAL/lib64 to $SAGE_LOCAL/lib (which rather incidentally is not a prerequisite for adding just -L$SAGE_LOCAL/lib here).

Change History (19)

comment:1 Changed 3 years ago by vbraun

  • Authors set to Volker Braun
  • Component changed from PLEASE CHANGE to build
  • Type changed from PLEASE CHANGE to defect

comment:2 Changed 3 years ago by ncohen

  • Cc ncohen added

comment:3 Changed 3 years ago by vbraun

  • Branch set to u/vbraun/globally_set__l_library_search_path

comment:4 Changed 3 years ago by git

  • Commit set to ce44e182e62cfea8f70a4dab4b6204bd5a18a394

Branch pushed to git repo; I updated commit sha1. New commits:

ce44e18Remove now-useless LDFLAGS modifications

comment:5 Changed 3 years ago by vbraun

  • Status changed from new to needs_review

comment:6 Changed 3 years ago by vbraun

  • Description modified (diff)

comment:7 Changed 3 years ago by leif

Can we get rid of the -Wl,-rpath,$SAGE_LOCAL/lib64? (Otherwise, we'd presumably have to add -L$SAGE_LOCAL/lib64 for consistency as well, which on the other hand doesn't make sense on 32-bit systems.)

After all, lib64 should be a symlink to lib (or the other way around), and we had tons of changes adding --libdir=$SAGE_LOCAL/lib to configure invocations a while ago. Probably meanwhile some are missing again.

comment:8 Changed 3 years ago by leif

  • Keywords LDFLAGS sage-env added

comment:9 follow-up: Changed 3 years ago by vbraun

GCC installs to /lib64, nothing else. GCC knows to link to its own libraries (so -L not needed) but at runtime it can fail (so rpath is needed).

I thought about the symlink solution and I would prefer that, but it should go to another ticket.

comment:10 in reply to: ↑ 9 Changed 3 years ago by leif

Replying to vbraun:

GCC installs to /lib64, nothing else. GCC knows to link to its own libraries (so -L not needed) but at runtime it can fail (so rpath is needed).

I thought about the symlink solution and I would prefer that, but it should go to another ticket.

Ok. Probably upon updating the GCC spkg... :P

comment:11 Changed 3 years ago by ncohen

I rebuilt Sage from scratch with this patch, and it does the job for me when building the latest release ended in a failure.

Thanks,

Nathann

comment:12 Changed 3 years ago by vbraun

  • Priority changed from major to blocker

comment:13 follow-up: Changed 3 years ago by leif

  • Cc jpflori fbissey added
  • Description modified (diff)

While the patch looks sane, I'd rather leave it up to sage-on-$foo maintainers / repackagers and users of exotic platforms to comment on and give it positive review, as it's a major change.

comment:14 in reply to: ↑ 13 Changed 3 years ago by fbissey

Replying to leif:

While the patch looks sane, I'd rather leave it up to sage-on-$foo maintainers / repackagers and users of exotic platforms to comment on and give it positive review, as it's a major change.

Well I don't use any of this mechanic to install sage-on-gentoo. I have a very simple sage-env that I ship in /etc but it is nowhere like the beast in vanilla. It just mirrors sage/env.py. On Gentoo prefix on the other hand I believe everything is wrapped to add the equivalent of your LDFLAGS and probably CPATH (for include path) but I am not sure of the details, I would have to dig - my own preference would be to wrap ld but I give hashdist a patch to insert a rpath in gcc's spec [this is highly platform dependent, I gave them x86_64 and arm but my OS X patch is not complete].

On gcc installing in lib64, hashdist's gcc doesn't. gcc on my prefix on a linux x86_64 machine doesn't.

comment:15 Changed 3 years ago by vbraun

Hashstack gcc.yaml does

  - name: link_lib64_to_lib
    after: install
    handler: bash
    bash: |
      # Create symbolic links from lib64/* to lib/
      cd ${ARTIFACT}/lib
      ln -s ../lib64/* .

comment:16 Changed 3 years ago by git

  • Commit changed from ce44e182e62cfea8f70a4dab4b6204bd5a18a394 to 34cba4c7171e9b3cc77d819cf0082243173dd267

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

01e22abGlobally set -L linker search path
34cba4cRemove now-useless LDFLAGS modifications

comment:17 Changed 3 years ago by vbraun

bump

comment:18 Changed 3 years ago by fbissey

  • Reviewers set to François Bissey
  • Status changed from needs_review to positive_review

comment:19 Changed 3 years ago by vbraun

  • Branch changed from u/vbraun/globally_set__l_library_search_path to 34cba4c7171e9b3cc77d819cf0082243173dd267
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.