Arch Linux

Here we go again. Reintroducing RPATH for the sake of  FS#27699  is just stupid compared to alternatives.

RPATH is set by upstream and is a sane value so we should keep it... What we should do is remove the ld.so.conf.d file now that RPATH has been reinstated.

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.

Will --enable-new-dtags prevent inheritance when linking against perl?

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

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)

Removing the ld.conf.so.d/ 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 libperl.so 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 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 to  FS#24660  to 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?

This should be fixed with perl 5.16.0-1. I removed the ld.so.conf 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.