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

[bugzilla at redhat.com]

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 at 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.