Opened 5 years ago

Last modified 5 years ago

## #23359 needs_info enhancement

# Don't embed rpaths during the build

Reported by: | Ximin Luo | Owned by: | |
---|---|---|---|

Priority: | minor | Milestone: | sage-8.0 |

Component: | build | Keywords: | |

Cc: | Merged in: | ||

Authors: | Ximin Luo | Reviewers: | |

Report Upstream: | N/A | Work issues: | |

Branch: | u/infinity0/don_t_embed_rpaths_during_the_build (Commits, GitHub, GitLab) | Commit: | d3d0f46c33eb5cd230247a30ecef4e7ea33b70b5 |

Dependencies: | Stopgaps: |

### Description (last modified by )

As per #22509, `DESTDIR`

is useful in the cases where the build process needs to hard-code `--prefix`

paths in the build output. For example, embedded rpaths. This is not only useful but vital for binary distros who can't write to /usr during a build.

It's less important - and one can get away with only supporting `--prefix`

- if the build does not embed these paths. However nowadays `DESTDIR`

is a common standard, so it's good to support it regardless.

Since Sage 8.0 currently does not support DESTDIR (and neither did previous versions) I have to carry the following patch in Debian. It would be technically unnecessary after DESTDIR support is introduced, however in Debian we also have a policy to avoid rpath if possible.

Even disregarding Debian, there is no particular reason for Sage to go embedding rpaths in its binaries, it prevents SAGE_LOCAL from being moved to different places around the filesystem. AFAICS, no other part of Sage involves embedding build paths, and one can freely move a SAGE_LOCAL around after applying this patch.

### Change History (8)

### comment:1 Changed 5 years ago by

Branch: | → u/infinity0/don_t_embed_rpaths_during_the_build |
---|

### comment:2 Changed 5 years ago by

Commit: | → d3d0f46c33eb5cd230247a30ecef4e7ea33b70b5 |
---|---|

Component: | PLEASE CHANGE → build |

Description: | modified (diff) |

Priority: | major → minor |

Status: | new → needs_review |

Type: | PLEASE CHANGE → enhancement |

### comment:3 Changed 5 years ago by

Authors: | → Ximin Luo |
---|

### comment:4 Changed 5 years ago by

Thou shall not use sage's provided `sage-env`

in sage-on-distro. Seriously don't :) I am even wondering why I contribute to it.

Setting rpath is sage as an arbitrary prefixed package's way to find its own stuff. Historically sage was using `LD_LIBRARY_PATH`

or equivalent. Which was also set in `sage-env`

.... To be clear if you remove the rpath and sage is not installed in system path, which is what happens for vanilla installs, someone will have to put `LD_LIBRARY_PATH`

back.

Which goes back to my point. My recommendation for fellow distros is just bring your own `sage-env`

, don't burden yourself with that bag of seemingly random stuff (it used to be worse much worse). It is just toxic to distros in this shape. May be if we rebuilt it from scratch using autotools it would be more palatable but that's much more than your small change here.

### comment:5 Changed 5 years ago by

Now Looking more closely I see you re-introduce `LD_LIBRARY_PATH`

(which is linux only, use DYLD_LIBRARY_PATH on OS X please). You could say the debate between rpath and LD_LIBRARY_PATH has already happened and a shift from one to the other was made.

So you want them to switch back... I am not sure what to say to you about that.

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

We don't ship Sage's own `sage-env`

, we took that tip off Gentoo a while ago. :) However we build with it for various reasons. For example, Sage needs access to `SAGE_SRC`

during the build, and various other things we don't put in our own `sage-env`

.

It seems OpenBSD and FreeBSD do support `LD_LIBRARY_PATH`

. I'm not sure when they added this, perhaps FreeBSD means Mac OS X now also supports it. Do you have a link to any threads on this topic? Maybe it's a good time for Sage to revisit this issue.

As I said, the main advantage is that `SAGE_LOCAL`

can be moved around. It's also useful for reproducible builds, which last time I checked, Sage was very close to achieving - there was only some Cython issue with embedded paths.

### comment:7 Changed 5 years ago by

Status: | needs_review → needs_info |
---|

There have been many discussions in the past about this... I don't know much about dynamic linking myself, but I do know that there are reasons why Sage uses rpaths.

At least this ticket should be discussed on sage-devel.

### comment:8 Changed 5 years ago by

Replying to infinity0:

We don't ship Sage's own

`sage-env`

, we took that tip off Gentoo a while ago. :) However we build with it for various reasons. For example, Sage needs access to`SAGE_SRC`

during the build, and various other things we don't put in our own`sage-env`

.

You can use `sage-env`

for that but really during the build of "sagelib" most thing are coming from `sage/env.py`

. Those value can be overridden by the environment which is the main reason my ebuild has the following section

export SAGE_LOCAL="${EPREFIX}"/usr export SAGE_ROOT=`pwd`/.. export SAGE_SRC=`pwd` export SAGE_ETC=`pwd`/bin export SAGE_DOC=`pwd`/build_doc export SAGE_DOC_SRC=`pwd`/doc export SAGE_DOC_MATHJAX=yes export VARTEXFONTS="${T}"/fonts export SAGE_VERSION=${PV} export SAGE_NUM_THREADS=$(makeopts_jobs)

`pwd`

in that context is the `src`

folder from the sage tarball. The build takes its cues from there.

Otherwise I agree with Jeroen. A flip back of this magnitude has to be discussed on sage-devel. Having an experience on HPC and various package managers which build software stack on top on an OS I fall heavily in the rpath camp. No solution to this problem is 100% perfect, but rpath now does it for me. Sage as a software stack falls in that category. This is of course different from the "sagelib" component itself, which should be free to have a life independent of the sage packaging system.

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

New commits:

`Prefer LD_LIBRARY_PATH to rpath so SAGE_LOCAL installs can be freely moved around`