December 2005 - perl-devel - Fedora Mailing-Lists

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

by Red Hat Bugzilla

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(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED ------- Additional Comments From jvdias(a)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.

18 years, 4 months

1
0
0 / 0

[Bug 172317] (libperl) could not run system-config-printer

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: (libperl) could not run system-config-printer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172317 nalin(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |161600 nThis| | Flag| |devel_ack+ -- 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.

18 years, 4 months

1
0
0 / 0

[Bug 145215] garbage after split()

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: garbage after split() https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145215 nalin(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-perl-devel- | |list(a)redhat.com | -- 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.

18 years, 4 months

1
0
0 / 0

[Bug 145215] garbage after split()

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: garbage after split() https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145215 nalin(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |161600 nThis| | Flag| |devel_ack+ -- 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.

18 years, 4 months

1
0
0 / 0

[Bug 135975] Perl's 'study' function breaks regexp matching

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Perl's 'study' function breaks regexp matching https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135975 nalin(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Q3 Errata Beta |3 OtherBugsDependingO| |161600 nThis| | Flag| |devel_ack+ -- 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.

18 years, 4 months

1
0
0 / 0

[Bug 172236] New: missing C standard headers

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172236 Summary: missing C standard headers Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list(a)redhat.com Description of problem: All perl versions on Linux / glibc / gcc systems fail to look for the C standard header files in the correct location, eg. : stddef.h syslimits.h stdarg.h float.h stdbool.h These are gcc built-in headers, and cpp searches for them in the gcc architecture specific include directory before the system include directory: /usr/lib/gcc/${arch}-${os}/${gcc-version}/include During the perl build, perl does not look for any headers in the gcc architecture specific include directory, but instead either fails to find the header at all, or finds versions of them used only by the kernel, eg. as shown by this excerpt from a log of a Rawhide perl build : --- + for i in asm/termios.h syscall.h syslimits.h syslog.h sys/ioctl.h sys/socket.h sys/time.h wait.h ... ... + /var/tmp/perl-5.8.7-0.5.fc5-root-jvdias//usr/bin/perl /var/tmp/perl-5.8.7-0.5.fc5-root-jvdias//usr/bin/h2ph -a -d /var/tmp/perl-5.8.7-0.5.fc5-root-jvdias/usr/lib/perl5/5.8.7/i386-linux-thread-multi syslimits.h Can't open syslimits.h: No such file or directory syslimits.h -> syslimits.ph --- ( empty syslimits.ph - no syslimits.ph shipped ) --- + /var/tmp/perl-5.8.7-0.5.fc5-root-jvdias//usr/bin/perl /var/tmp/perl-5.8.7-0.5.fc5-root-jvdias//usr/bin/h2ph -a -d /var/tmp/perl-5.8.7-0.5.fc5-root-jvdias/usr/lib/perl5/5.8.7/i386-linux-thread-multi asm/termios.h ... linux/stddef.h -> linux/stddef.ph --- No <stddef.h> shipped, only <linux/stddef.h>, which is meant to be used only by the kernel. This results in many system headers that reference the C standard headers being unusable because the C standard headers are not found (eg. sys/resource.ph -> bits/resource.ph -> linux/types.ph -> stddef.ph -> stddef.ph not found, bug 170088 ). The perl build process should find the C standard headers in their correct location, as many system perl headers that are shipped by perl reference them. Version-Release number of selected component (if applicable): ALL How reproducible: 100% Steps to Reproduce: $ perl -e 'require "sys/resource.ph";' Actual results: Fails due to missing stddef.ph Expected results: No error Additional info: -- 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.

18 years, 4 months

1
6
0 / 0

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

by Red Hat Bugzilla

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 nalin(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |175104 nThis| | -- 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.

18 years, 4 months

1
0
0 / 0

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

by Red Hat Bugzilla

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 wtogami(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|150221 |136452 nThis| | -- 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.

18 years, 4 months

1
0
0 / 0

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

by Red Hat Bugzilla

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 jorton(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jorton(a)redhat.com ------- Additional Comments From jorton(a)redhat.com 2005-12-06 04:21 EST ------- This is a regression, can you revert this change until something better is found? We will start accumulating packages containing binaries with bogus RPATHs again for as long as this perl package remains in the buildoot. -- 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.

18 years, 4 months

1
0
0 / 0

[Bug 174795] mod_perl broken by perl-5.8.5-18.FC3 security update

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: mod_perl broken by perl-5.8.5-18.FC3 security update https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174795 ------- Additional Comments From nigel(a)dev.intechnology.co.uk 2005-12-05 05:51 EST ------- Confirm my problem resolved with this combination of pckages:- perl-5.8.5-20.FC3 mod_perl-1.99_16-3 httpd-2.0.53-3.3 -- 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.

18 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel December 2005