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:

Status badges

Description (last modified by Ximin Luo)

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 Ximin Luo

Branch: u/infinity0/don_t_embed_rpaths_during_the_build

comment:2 Changed 5 years ago by Ximin Luo

Commit: d3d0f46c33eb5cd230247a30ecef4e7ea33b70b5
Component: PLEASE CHANGEbuild
Description: modified (diff)
Priority: majorminor
Status: newneeds_review
Type: PLEASE CHANGEenhancement

New commits:

d3d0f46Prefer LD_LIBRARY_PATH to rpath so SAGE_LOCAL installs can be freely moved around

comment:3 Changed 5 years ago by Ximin Luo

Authors: Ximin Luo

comment:4 Changed 5 years ago by François Bissey

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.

Last edited 5 years ago by François Bissey (previous) (diff)

comment:5 Changed 5 years ago by François Bissey

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 Changed 5 years ago by Ximin Luo

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 Jeroen Demeyer

Status: needs_reviewneeds_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 in reply to:  6 Changed 5 years ago by François Bissey

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.