FS#27173 - [perl] Remove RPATH
Attached to Project:
Arch Linux
Opened by Jason William Walton (jasonww) - Sunday, 20 November 2011, 17:15 GMT
Last edited by Allan McRae (Allan) - Saturday, 02 June 2012, 13:14 GMT
Opened by Jason William Walton (jasonww) - Sunday, 20 November 2011, 17:15 GMT
Last edited by Allan McRae (Allan) - Saturday, 02 June 2012, 13:14 GMT
|
Details
Currently, libperl is unnecessarily RPATH enabled. This
seems pointless given that /etc/ld.so.conf.d/perl.conf comes
with the package.
The offending lines in Configure: bsdos|linux|irix*|dec_osf|gnu*) xxx="-Wl,-rpath,$shrpdir" ;; Using sed to remove the contents is enough. Rationale: 1) Useless. 2) Stuff that properly links against perl usually inherits the RPATH from perls LDFLAGS which kinda sucks. 3) Adds minor startup latency. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 02 June 2012, 13:14 GMT
Reason for closing: None
Additional comments about closing: perl 5.16.0-1
Saturday, 02 June 2012, 13:14 GMT
Reason for closing: None
Additional comments about closing: perl 5.16.0-1
FS#27699is just stupid compared to alternatives.At least use -Wl,--enable-new-dtags for perl so LD_LIBRARY_PATH works as expected. (Also required to make the test suite work correctly I think.
Also, how about moving libperl.so to /usr/lib, adding a soname[1] and removing the ld.so.conf.d file? I know we shouldn't patch, but moving a lib without a version to /usr/lib feels wrong.
[1]: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/libperl/files/libperl-create-libperl-soname.patch?view=markup
0x000000000000000f (RPATH) Library rpath: [/usr/lib64/perl5/CORE]
0x000000000000001d (RUNPATH) Library runpath: [/usr/lib64/perl5/CORE]
Anyway, this bug really isn't of any importance, do whatever you want.
For your sanity, try to build without !makeflags - worked for me on a fairly fast machine.
TEST_JOBS=$(echo $MAKEFLAGS | sed 's/.*-j\([0-9][0-9]*\).*/\1/') make test_harness
to run the test suite in parallel as well. (Stolen from Fedoras spec file)
Every bug that has been reported about this has been misinformed.
FS#23022began the idea to add an ld.conf script. It was not a bug. The bug reports that a perl module is linking to libperl.so and can't locate it. Perl modules are loaded by the /usr/bin/perl interpreter. At this time libperl.so is obviously already loaded. This report led toFS#24660to fix the supposed bug. This bug report led to commit 83821d6 which added /etc/ld.so.conf.d/perl.conf. The better solution would be to fix namcap's heuristics to match the working system instead of trying to match the system to namcap's heuristics.We are basically chasing our own tail here by fixing phantom bugs. libperl.so is not like other libraries and should not be pigeon-holed as such. Like I said above, when a program wants to link with libperl.so, it asks the interpreter. A linking program does this either through ExtUtils::Embed or perl -V:ccdlflags, etc. This is not typical of dynamic libraries. Moving it to /usr/lib is IMO pointless and, again, trying to fix something that isn't broken. By previous arrangement nothing should link to libperl.so on its own accord, it goes through /usr/bin/perl.
jasonww:
1) The RPATH is not useless. The /etc/ld.so.conf.d/perl.conf file is.
2) Uh?
3) Got any benchmarks?
4) LD_LIBRARY_PATH does work as I expect it to (LD_LIBRARY_PATH=. ldd ./perl when building perl)
5) The test suite sets LD_LIBRARY_PATH in its Makefile when 'make test' is run.
Re-added TEST_JOBS is of course good. It went missing for some reason. Not sure why !makeflags is there. I suspect that perl uses the Configure script to set these flags instead of using the environment variables. I don't have time to read the Makefile right now. However, these are unrelated to this bug report.
I still have to check every package that links to libperl.so directly, in order to embed an interpreter, to make sure that it has an RPATH. Maybe afterwards we can remove the perl.conf file and close this bug?
I'll close this when perl moves from testing to core.