[Bug 136009] MakeMaker::MM_Unix doesn't honor LD_RUN_PATH requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Fedora PHP Devel]     [Kernel Devel]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite Information]
  Powered by Linux