On Fri, Oct 07, 2005 at 12:38:48AM +0100, Philip Martin wrote:
> 
> 
> It's the second build that fails, when this libtool command:
> 
> libtool --mode=link    gcc zz/k/k.lo zz/j/libj.la -o zz/k/k
> 
> invokes this gcc command:
> 
> gcc zz/k/.libs/k.o -o zz/k/.libs/k  zz/j/.libs/libj.so  -Wl,--rpath 
> -Wl,/home/pm/sw/zz/lib
> 
> Note the --rpath to the install directory, that goes straight through
> to the linker, and it appears that the command line option overrides
> RPATH in the library.  Is it a linker bug for the command line option
> to have priority?  I don't know.

>From the documentation:
       -rpath dir
           Add a directory to the runtime library search path.  This  is  used
           when  linking  an  ELF  executable with shared objects.  All -rpath
           arguments are concatenated and passed to the runtime linker,  which
           uses  them  to locate shared objects at runtime.  The -rpath option
           is also used when locating  shared  objects  which are  needed  by
           shared objects explicitly included in the link; see the description
           of the -rpath-link option.

And -rpath-link has this nice order:
           1.  Any directories specified by -rpath-link options.
           2.  Any directories specified by -rpath  options.  [...]
[...]
           5.  For  a  native linker, the contents of the environment variable
               "LD_LIBRARY_PATH".
           6.  For a native ELF linker, the  directories  in "DT_RUNPATH"  or
               "DT_RPATH"   of  a  shared  library  are  searched for  shared
               libraries needed by it. The "DT_RPATH" entries are ignored  if
               "DT_RUNPATH" entries exist.
           7.  The default directories, normally /lib and /usr/lib.
           8.  For   a   native   linker   on  an  ELF  system, if  the  file
               /etc/ld.so.conf exists, the list of directories found  in  that
               file.


So it seems that the -rpath option to the install dir might be
the problem.  Or maybe an LD_LIBRARY_PATH?

> Perhaps libtool should not be passing that --rpath during the link?
> Perhaps libtool should be passing the build dir instead?  (That might
> mean that libtool has to relink the executable at install time to get
> the correct final rpath.)  Does that make it a libtool bug?

You might be right about this, and I will take a look at it.

Any idea why libtool passes the install path in the first place?
How should it know where it's going to get installed at this
point?


PS: This might actually be the wrong bug in which we're
discussing this.


Kurt



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to