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@xxxxxxxxxx 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.
