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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
