[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
------- Additional Comments From bojan(a)rexursive.com 2005-12-08 23:55 EST -------
If I may ask a question similar to the one in comment #19, but Perl unrelated:
what is the recommended way of building a package that ships both a library one
of its binaries depends on and the binary itself? I bumped into this problem a
while back when building (on current Rawhide) one of my (still not in FE)
packages. Basically, this is the situation:
Package is supposed to build and distribute:
- a binary (which happens to be an Apache module)
- a library to which the binary links, which will eventually be installed into
the system location (i.e. /usr/lib or /usr/lib64)
During the build (in the user's home directory), the build process encodes RPATH
of the library (something like /home/<user>/rpmbuild/blah/blah) into the binary.
One of the build scripts then checks rpaths and bombs out, saying that you can't
have that kind of stuff in the shipped binary. Which is, of course correct, but
I never asked for those to be encode in the first place ;-)
Is there a way to strip RPATHs from the libary or force some RPATHs not be
picked in some "proper" manner? I currently do this kind of trickery in my
Makefile.am to avoid the situation (basically I relink with RPATHs stripped):
eval "`eval \"echo $(LINK) $(mod_spin_la_LDFLAGS) $(mod_spin_la_OBJECTS)
$(mod_spin_la_LIBADD) $(LIBS) | sed -e s/'libtool'/'libtool -n'/ -e
s/'install-exec-hook'/'mod_spin.la'/g\" | sed -e s@'-Wl,[-]\+rpath -Wl,[^ ]\+
'@''@g -e s@'-L\(/usr\)*/lib\(64\)*\($$\| \)'@''@g`"
Ugly, error prone and most likely not generic enough. Suggestions, solutions and
advice welcome. Please be gentle, I'm no expert in this (as if that wasn't
obviuos enough already :-)
--
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, 5 months
[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
------- Additional Comments From jvdias(a)redhat.com 2005-12-08 17:49 EST -------
RE: Comment #20:
Yes, I think one should easily be able to restore the generated LD_RUN_PATH
usage EITHER by setting the USE_MM_LD_RUN_PATH MM object member OR by setting
a USE_MM_LD_RUN_PATH environment variable, so no scripts would have to be
modified.
I'll ensure you'll still be able to use an explicit LD_RUN_PATH
environment variable setting during a MakeMaker build.
I think it is rather broken that EVERY -L option becomes a member of
LD_RUN_PATH - all that would have to happen is for a library not to be
installed in the system library directories, and for the build tree to
have disappeared, and then the app won't link. It is also unreasonable
to install an RPATH header containing references to the non-existent
build tree directories in EVERY object created using -L during a system
build of all perl modules in the Red Hat build tree.
RE: Comment #19 :
Interesting point about -rpath-link, but on further investigation I think
probably MakeMaker is doing the right thing by ignoring the -rpath-link
option - it is only of relevance to the linker in resolving dependencies
of libraries linked to -l, not in resolving the -l library locations
themselves.
-rpath-link is no replacement for -L : it is used only when
doing a "non-shared, non-relocatable link" - ie. an executable -
to resolve dependencies of one shared library, linked to with -l (and
presumably found using -L or -rpath ) on another shared library, NOT
specified explicitly with -l .
-rpath-link operates exactly like LD_LIBRARY_PATH, and LD_LIBRARY_PATH will be
used for this purpose if the library is not found in directories specified
by any of the -rpath, -L, or -rpath-link options.
ie if you have this setup:
executble ./t links to -lg and calls g() in lg/libg.so;
./lg/libg.so links to -lf, which should resolve to ./lf/libf.so,
and g() calls f() in libf.so
If you produce libg.so as follows:
$ cd lg
$ gcc -shared -o libg.so g.o -L../lf -lf
and then you try to link t:
$ gcc -o t t.o -Llg -lg
/usr/bin/ld: warning libf.so, needed by ld/libg.so, not found (try using
-rpath or -rpath-link)
lg/libg.so: undefined reference to `f'
This can be resolved by doing:
$ LD_LIBRARY_PATH=lf gcc -o t t.o -Llg -lg
OR by doing
$ gcc -o t t.o -Wl,-rpath-link,lf -Llg -lg
OR if libgo.so was linked with
$ gcc -o libg.so -shared -Wl,-rpath,lf -L../lf g.o -lf
and t could then be linked with:
$ gcc -o t m.o -Llg -lg
But -rpath-link would NOT be used when linking libg.so with libf.so:
$ cd lg;
$ gcc -o libg.so -shared -Wl,-rpath-link,../lf -lf
/usr/bin/ld: cannot find -lf
You HAVE to use -L../lf or -Wl,-rpath,../lf for the libg.so link to succeed.
So I'm not sure that MakeMaker could do anything useful with -rpath-link options
- if you disagree, please let me know.
--
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, 5 months
[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
------- Additional Comments From ville.skytta(a)iki.fi 2005-12-08 15:30 EST -------
Not an objection, but a comment/question:
Would -rpath-link=/some/where be the "correct" thing to use in cases like
subversion-perl and libapreq2 (in Extras) where a lib needs to be linked with
another one produced during the same build, but not found without specifying the
directory to them? If so, ExtUtils::Liblist::Kid::_unix_os2_ext() could perhaps
be taught about that (+ the corresponding -Wl,rpath-link,...), which it would
process more or less like -L apart from not stuffing it into LD_RUN_PATH.
Currently if one tries to use -Wl,rpath-link, MM doesn't recognize the option
which seems to eventually lead to libs in that dir not being found by
_unix_os2_ext() and consequently dropped from the list of libs to actually link
with.
--
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, 5 months
[Bug 173053] Review Request: perl-Readonly-XS
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: Review Request: perl-Readonly-XS
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173053
------- Additional Comments From mpeters(a)mac.com 2005-12-08 15:19 EST -------
(In reply to comment #8)
> when unbundled, some of that pain is outsourced to end users as non-obviousness.)
Yeah - I agree - users have to know they need to request this to get the speed
bump. Too bad rpm doesn't have a "Suggests" tag to install if configured to do
so, or ignore if configured to do so.
Build machines could ignore it, but end user machines could (by default) install
it if available - but not choke and die if not available.
--
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, 5 months
[Bug 173053] Review Request: perl-Readonly-XS
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: Review Request: perl-Readonly-XS
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173053
------- Additional Comments From ville.skytta(a)iki.fi 2005-12-08 14:58 EST -------
(In reply to comment #4)
> I guess I'm going to have to remove the requires from the other package, which
> is unfortunate because it means yum won't automagically pull in this one.
I still think that bundling these two would have been acceptable in this case
and would have personally gone that way. Sure, there are arguments why doing so
isn't that nice, so it's a matter of the maintainer picking his poison. (Well,
when unbundled, some of that pain is outsourced to end users as non-obviousness.)
--
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, 5 months
[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
------- Additional Comments From jvdias(a)redhat.com 2005-12-08 14:54 EST -------
OK, I'll submit to popular request, and restore the previous default
behavior of previous Red Hat perl releases to remove the MakeMaker generated
LD_RUN_PATH by default .
I'll ensure that users are still able to set the LD_RUN_PATH environment
variable during builds and that it will take effect if non empty .
Also, as this removal of the MakeMaker generated LD_RUN_PATH contravenes
the default upstream behavior and documentation, I'll ammend the MakeMaker
POD documentation to explicitly state that the Red Hat distribution
removes the MakeMaker generated LD_RUN_PATH.
I think also we should give users a means to direct that the MakeMaker
generated LD_RUN_PATH should be used; I'll add a "USE_MM_LD_RUN_PATH"
member of the MakeMaker object that can be set , and document this also.
Please send any objections / suggestions ASAP - thanks .
--
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, 5 months