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@xxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED ------- Additional Comments From jvdias@xxxxxxxxxx 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.
