Matthias Ferdinand <mf+ml.pkgsrc-users%netzwerkagentursaarland.de@localhost> writes: > upgrading python27 from 2.7.3nb3 to 2.7.6nb2 failed on my Linux > installations (except for some older than ~6 years). > > On Linux at least, RPATH has precedence over LD_LIBRARY_PATH. Pkgsrc > uses RPATH to direct its binaries to the pkgsrc installed libraries > instead of the system libraries. RPATH taking precedence over LD_LIBRARY_PATH sounds broken. Can you point to any specfications that say this is reasonable? > This breaks pythons use of LD_LIBRARY_PATH for the build process, > resulting in the use of a previously installed libpython2.7.so instead > of the just compiled current version. The build succeeds if no previous > python27 is installed (package removed or libpython2.7.so renamed). > > See here for a nice summary of the RPATH vs. LD_LIBRARY_PATH problem: > http://postgresql.1045698.n5.nabble.com/LD-LIBRARY-PATH-versus-rpath-td2017872.html > > Attached is a patch for Makefile.pre.in. To work around the issue, it > creates a copy of the ./python binary, removes the RPATH setting using > chrpath, and uses the resulting binary for further local python invocations. > > The patch probably lacks in elegance, and possibly in portability (does > chrpath exist for every pkgsrc platform?). The pkgsrc Makefile also > needs an additional USE_TOOLS+=chrpath for this patch. chrpath seems like something that's best not to pull in. I wonder if this should be done only on platforms which have the RPATH/LD_LIBRARY_PATH problem. When people build python on Linux using Linux packaging systems, how does that work?
Attachment:
pgp4vHlq4FpNo.pgp
Description: PGP signature