Opened 11 years ago

Closed 6 years ago

## #11681 closed defect (fixed)

# Mac Binary distribution contains hardcoded absolute paths

Reported by: | Alexander Dreyer | Owned by: | Georg S. Weber |
---|---|---|---|

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 11 years ago by

### comment:2 Changed 11 years ago by

The counterpart of "chrpath" on OS X is called "install_name_tool", FWIW.

### comment:3 Changed 11 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 11 years ago by

(**Any** definition of `SAGE_ROOT`

in `local/lib/pkgconfig/*.pc`

can and should be removed.)

### comment:5 follow-up: 6 Changed 11 years ago by

Replying to leif:

(

Anydefinition of`SAGE_ROOT`

in`local/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 Changed 11 years ago by

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.

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 9 years ago by

Milestone: | sage-5.11 → sage-5.12 |
---|

### comment:8 Changed 9 years ago by

Milestone: | sage-6.1 → sage-6.2 |
---|

### comment:9 Changed 9 years ago by

Milestone: | sage-6.2 → sage-6.3 |
---|

### comment:10 Changed 8 years ago by

Milestone: | sage-6.3 → sage-6.4 |
---|

### comment:12 Changed 7 years ago by

Milestone: | sage-6.4 → sage-duplicate/invalid/wontfix |
---|---|

Reviewers: | → Jeroen Demeyer |

Status: | new → needs_review |

Obsolete by the new binary packaging.

### comment:13 Changed 7 years ago by

Status: | needs_review → positive_review |
---|

### comment:14 follow-up: 15 Changed 7 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 Changed 7 years ago by

### comment:16 Changed 6 years ago by

Resolution: | → fixed |
---|---|

Status: | positive_review → closed |

**Note:**See TracTickets for help on using tickets.

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 on`LD_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.