Re: interdependent shared library problem

[Patrick Welche]

On Sat, Oct 21, 2006 at 01:31:53PM +0200, Ralf Wildenhues wrote:
> Hello Patrick,
> 
> * Patrick Welche wrote on Mon, Oct 16, 2006 at 01:17:42PM CEST:
> > 
> > /usr/X11R6/lib doesn't need to be in the default set of paths searched
> > by the loader. As I mentioned, with a different compile line to the one
> > generated by libtool, I have a working hello. The problem is that the
> > binary created by libtool contains the dependencies of the shared the
> > library rather than just depending on the shared library.
> 
> No.  The bug is that the -R information isn't also transferred to the
> program.  The (known) Libtool limitation is that it does not implement
> a consistent set of semantics for indirect library dependencies.
> (Note there are systems which don't have such.)

It isn't a known libtool limitation to me - though given everyone's
silence, I thought I had touched on past history. When reading the
mail archives on library dependencies, the example used is often
something really complicated, so I thought posting a simple reproducible
one would keep on target.

> I'm not sure why -R isn't transferred, but somebody may have had some
> good reason for it.  Who knows.

So, what you are saying is, it isn't that the binary includes the
bin -> libB dependency as well as the bin -> libA dependency which is
the problem, but that bin isn't getting libB's rpath? Sounds good to
me (I was actually surprised that by-hand gcc line worked)

libhello.la contains
dependency_libs=' -R/usr/X11R6/lib  -L/usr/X11R6/lib -lSM -lICE'

and the final link line is

/bin/ksh ./libtool --tag=CC --mode=link gcc -g -O2 -o hello main.o libhello.la 

but this happens

libtool: link: gcc -g -O2 -o .libs/hello main.o  ./.libs/libhello.so 
-L/usr/X11R6/lib -lSM -lICE -Wl,-rpath -Wl,/usr/local/lib

so the -R was removed from dependency_libs to generate the linking command?

Thoughts?

Cheers,

Patrick