Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Angel Velasquez (angvp)
Florian Pritz (bluewind)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Currently, libperl is unnecessarily RPATH enabled. This seems pointless given that /etc/ comes with the package.

The offending lines in Configure:


Using sed to remove the contents is enough.


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
Comment by Jason William Walton (jasonww) - Tuesday, 03 January 2012, 01:07 GMT
Here we go again. Reintroducing RPATH for the sake of  FS#27699  is just stupid compared to alternatives.
Comment by Allan McRae (Allan) - Tuesday, 03 January 2012, 01:08 GMT
RPATH is set by upstream and is a sane value so we should keep it... What we should do is remove the file now that RPATH has been reinstated.
Comment by Jason William Walton (jasonww) - Tuesday, 03 January 2012, 08:55 GMT
Thats going to break some blobs and everything else that does link against perl directly without RPATH. Not a very good idea to get rid of it just yet.

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.
Comment by Florian Pritz (bluewind) - Tuesday, 03 January 2012, 18:28 GMT
Will --enable-new-dtags prevent inheritance when linking against perl?

Also, how about moving to /usr/lib, adding a soname[1] and removing the file? I know we shouldn't patch, but moving a lib without a version to /usr/lib feels wrong.

Comment by Jason William Walton (jasonww) - Tuesday, 03 January 2012, 18:57 GMT
No it won't as seen on Fedoras /usr/bin/vim:

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)
Comment by Justin Davis (juster) - Sunday, 15 January 2012, 15:49 GMT
Removing the file would only break packages that were built when the build system's installed perl package was missing the RPATH. Programs that need to link to in order to EMBED perl actually run the perl binary (/usr/bin/perl) to use the same compiler and linker flags that perl used when it was compiled. This includes the -rpath flag.

Every bug that has been reported about this has been misinformed.

 FS#23022  began the idea to add an ld.conf script. It was not a bug. The bug reports that a perl module is linking to and can't locate it. Perl modules are loaded by the /usr/bin/perl interpreter. At this time is obviously already loaded. This report led to  FS#24660  to fix the supposed bug. This bug report led to commit 83821d6 which added /etc/ 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. is not like other libraries and should not be pigeon-holed as such. Like I said above, when a program wants to link with, 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 on its own accord, it goes through /usr/bin/perl.

1) The RPATH is not useless. The /etc/ 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 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?
Comment by Florian Pritz (bluewind) - Sunday, 27 May 2012, 07:47 GMT
This should be fixed with perl 5.16.0-1. I removed the and we rebuilt everything, so unless the build scripts are broken the rpath should be there.

I'll close this when perl moves from testing to core.