Opened 10 years ago
Closed 5 years ago
#11681 closed defect (fixed)
Mac Binary distribution contains hardcoded absolute paths
Reported by: | AlexanderDreyer | Owned by: | GeorgSWeber |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | build | Keywords: | Mac build paths |
Cc: | Merged in: | ||
Authors: | Reviewers: | Jeroen Demeyer | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
At least the following image:
http://boxen.math.washington.edu/sage/osx/intel/sage-4.7-OSX-64bit-10.6-i386-Darwin.dmg
is defect. The build contains hardcode *absolute* paths the dynamic libs, e.g. something like libpng12.dynlib
is looked up at /Users/buildbot/build...
.
This makes it impossible to install spkgs which depend on libraries delivered by Sage. For instance, the spkg/patch from #11575 builds and installs, but is corrupted afterwards.
Change History (16)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
The counterpart of "chrpath" on OS X is called "install_name_tool", FWIW.
comment:3 Changed 10 years ago by
Alexander, just curious:
How does your $SAGE_ROOT/local/lib/pkgconfig/libpng12.pc
file look like (especially the first line)?
comment:4 follow-up: ↓ 5 Changed 10 years ago by
(Any definition of SAGE_ROOT
in local/lib/pkgconfig/*.pc
can and should be removed.)
comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 10 years ago by
Replying to leif:
(Any definition of
SAGE_ROOT
inlocal/lib/pkgconfig/*.pc
can and should be removed.)
I'm meanwhile no longer sure about that, since (to me) it looks as if pkg-config
's behaviour has changed.
The following is definitely invalid and should be removed:
(I've seen this as a result of a build from scratch; reinstalling e.g. libpng12
cured this.)
SAGE_ROOT=${SAGE_ROOT}
The following are both ok (at least until the Sage installation moves, which sage
will notice upon start-up, then correcting / updating the path in the .pc
files):
prefix=/current/path/to/SAGE_ROOT/local ...
SAGE_ROOT=/current/path/to/SAGE_ROOT prefix=${SAGE_ROOT}/local ...
Unfortunately, the correction of the paths in .pc
files (as performed by sage-location
) isn't fully reliable at the moment, as the first example above shows.
Furthermore, sage-env
is broken in that it currently only sets (i.e., "overwrites") PKG_CONFIG_PATH
to $SAGE_ROOT/local/lib/pkgconfig/
if it is empty / undefined, instead of also prepending Sage's pkg-config
directory otherwise.
This means that PKG_CONFIG_PATH
should currently be unset (outside of the Sage environment) before installing or rebuilding any package.
comment:6 in reply to: ↑ 5 Changed 10 years ago by
Unfortunately, the correction of the paths in
.pc
files (as performed bysage-location
) isn't fully reliable at the moment, as the first example above shows.
As you know, this causes problems elsewhere as well. Is there a way to grep through this particular one and find all the places this is a problem?
comment:7 Changed 8 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:8 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:9 Changed 7 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:10 Changed 7 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:11 Changed 6 years ago by
Is this still an issue?
comment:12 Changed 5 years ago by
- Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
- Reviewers set to Jeroen Demeyer
- Status changed from new to needs_review
Obsolete by the new binary packaging.
comment:13 Changed 5 years ago by
- Status changed from needs_review to positive_review
comment:14 follow-up: ↓ 15 Changed 5 years ago by
Really, are you sure there no "buildbot" or "buildslave" things? I note that we still occasionally get such questions on ask.sagemath.
comment:15 in reply to: ↑ 14 Changed 5 years ago by
comment:16 Changed 5 years ago by
- Resolution set to fixed
- Status changed from positive_review to closed
An ugly work-around is to create the original build directory (which ordinary users may not be able to), and make it a symbolic link to the new location (
$SAGE_ROOT
).In principle all shared libraries should have relative
RUNPATH
s. AFAIK currently most just use the library name (i.e., no [absolute] path), but rely onLD_LIBRARY_PATH
(DYLD_LIBRARY_PATH
on Darwin) instead.For ELF on UNIX / Linux etc., there is a tool
chrpath
(change run path) to (partially) fix such things in already built libraries and executables; I don't know if there's something similar available on Darwin.