[Bug 136009] MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
bugzilla at redhat.com
bugzilla at redhat.com
Tue Dec 6 21:28:31 UTC 2005
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136009
jvdias at redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |MODIFIED
------- Additional Comments From jvdias at redhat.com 2005-12-06 16:28 EST -------
The default behaviour of the unmodified MakeMaker package, and the latest 6.30
upstream version, is to add every directory specified in the MakerMaker object's
LIBS into the LD_RUN_PATH environment variable setting used by the ld(1)
command, as documented in 'man ExtUtils::Liblist' :
" LDLOADLIBS and LD_RUN_PATH
List of those libraries which can or must be linked into the shared
library when created using ld. These may be static or dynamic
libraries. LD_RUN_PATH is a colon separated list of the directories in
LDLOADLIBS. It is passed as an environment variable to the process that
links the shared library.
"
So the ExtUtils::Liblist::Kid::_unix_os2_ext function creates the LD_RUN_PATH
setting from the list of libraries to be linked.
IF no explicit -rpath argument is given to ld(1), it will use a non-empty
LD_RUN_PATH environment variable setting as the object's RPATH .
Previously, we had removed use of LD_RUN_PATH by MakeMaker altogether
with the 'perl-5.8.3-empty-rpath.patch' - this was somewhat draconian,
especially as it contravenes the shipped documentation about LD_RUN_PATH
usage.
We've now restored the default upstream MakeMaker LD_RUN_PATH behavior, with
a patch to remove an empty LD_RUN_PATH setting similar to that suggested by
Rafael in Comment #6 above with Mandriva's perl-5.8.5-removeemptyrpath.patch,
which is now in the upstream MakeMaker 6.30 release .
LD_RUN_PATH usage is still entirely under the control of module developers .
The Red Hat build root environment contains no LD_RUN_PATH setting .
It is not the case that "we will start accumulating packages containing
binaries with bogus RPATHs" - only if packages pass LIBS with absolute
full paths into the buildroot will this occur, and if it does occur, it is
only a problem if the libraries are shipped in non-standard locations,
in which case it is also a module packaging issue, and would not be corrected
by reverting the change .
With subversion-perl, for instance, it contains paths into the build root
in its Makefile.PL LIBS setting :
---
...
my @ldpaths = ("$swig_builddir/perl/libsvn_swig_perl/.libs",
map {"$svnlib_builddir/libsvn_$_/.libs"} (@modules, qw/diff subr
ra_local
ra_svn
ra_dav
fs_base
fs_fs/));
...
my %config = (
...
LIBS => [join(' ', $apr_ldflags,
(map {$_ = abs_path($_); "-L$_"} @ldpaths),
@ldmodules, '-lsvn_swig_perl-1',
`$swig -perl -ldflags`)],
...
);
...
WriteMakefile(%config, ...
---
And the subversion-perl .so objects end up with these horrible RPATH settings:
$ objdump -x ./vendor_perl/5.8.7/i386-linux-thread-multi/auto/SVN/_Core/_Core.so
| grep RPATH
RPATH
/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_client/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_delta/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_fs/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_ra/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_repos/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_wc/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_diff/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/libsvn_subr/.libs:/usr/src/build/652335-i386/BUILD/subversion-1.2.3/subversion/bindings/swig/perl/libsvn_swig_perl/.libs
But the loader still finds the SVN libraries, because they are shipped in the
default system library path :
$ ldd ./vendor_perl/5.8.7/i386-linux-thread-multi/auto/SVN/_Core/_Core.so
linux-gate.so.1 => (0x00b71000)
libsvn_client-1.so.0 => /usr/lib/libsvn_client-1.so.0 (0x00790000)
libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0x00bb6000)
libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0x006eb000)
libsvn_ra-1.so.0 => /usr/lib/libsvn_ra-1.so.0 (0x00bea000)
libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0x00ca0000)
libsvn_wc-1.so.0 => /usr/lib/libsvn_wc-1.so.0 (0x00cfd000)
libsvn_diff-1.so.0 => /usr/lib/libsvn_diff-1.so.0 (0x00e10000)
libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0x00801000)
libsvn_swig_perl-1.so.0 => /usr/lib/libsvn_swig_perl-1.so.0 (0x00b76000)
...
What subversion-perl could have done was specify its list of build tree
.libs library locations in $LD_LIBRARY_PATH and specify its libs only as
-l options - then no RPATH would have being inserted in the .so objects.
So this issue creates no problems for perl module shared objects which link to
libraries shipped in the standard locations; also, modules are now enabled to
link to libraries that are not in standard locations, simply by putting
the full path to the library in the MakeMaker object's LIBS .
RE:
> Another example would be to rebuild perl-Compress-Zlib with the new perl and
> witness how /usr/lib, a standard system dir, is unnecessarily stuffed into a
> rpath.
I don't see this problem when building with the latest perl on
FC-3, FC-4, FC-5, or RHEL-4:
$ rpm -q perl-Compress-zlib
perl-Compress-zlib-1.41-1
$ objdump -x
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Compress/Zlib/Zlib.so
| grep RPATH
$ cd ~/.cpan/build/Compress-Zlib-1.41
$ perl Makefile.PL
...
$ make
...
$ objdump -x ./blib/arch/auto/Compress/Zlib/Zlib.so | grep RPATH
$
So, in conclusion, I think we should retain the default upstream
MakeMaker LD_RUN_PATH behaviour, allowing module developers to
use libraries in non-standard locations, and also requiring module
developers to be careful about what paths they include in LIBS .
This issue is not a "regression", as no actual problems are caused by it,
and perl now has default upstream behaviour in this respect; perhaps it
was a "regression" when the perl-5.8.3-empty-rpath.patch removed support
for LD_RUN_PATH contrary to the shipped perl documentation, and this
"regression" has now been corrected.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the Fedora-perl-devel-list
mailing list