[ Cc: to libtool mailing list. This thread is at http://thread.gmane.org/gmane.os.openbsd.ports/14993 and the interesting bit starts at the end of this post: http://article.gmane.org/gmane.os.openbsd.ports/15121 ]
* Ralf Wildenhues wrote on Sun, Nov 27, 2005 at 09:06:09AM CET: > * Jacob Meuser wrote on Sun, Nov 27, 2005 at 05:42:07AM CET: > > On Wed, Nov 23, 2005 at 05:04:07PM +0000, Ralf Wildenhues wrote: > > > Marc Espie <espie <at> nerim.net> writes: > > > > > > I'm very annoyed at > > > > libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la > > > > expanding into some stuff like: > > > > cc -L/usr/local/lib -L. -o foo foo.o -lbar > > > > which gets us the libbar installed under /usr/local/lib instead of the > > > > one > > > > we just built... > > > > > > Genuine bug in Libtool's OpenBSD support, most likely some wrong > > > assumption > > > about which path overrides which. Current branch-1-5 does not do this on > > > GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to > > > OpenBSD. > > > > > > For static libbar, it creates on both systems > > > gcc -o foo foo.o ./.libs/libbar.a > > > and for shared libbar it creates > > > gcc -o .libs/foo foo.o ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst > > > > I think you are not understanding Marc's point. > > No, but I pasted the output in a misleading way. > > > what happens with -L/usr/local/lib? > > Libtool knows that the library is uninstalled, because this information > is encoded in libbar.la, hence knows to hardcode it _even_ when the > installed path is given first. Attached an example. Please modify so > it fails on OpenBSD. OK. This fails on OpenBSD because of hardcode_direct=yes, all branches, I assume, because then libtool will create cc -L/usr/local/lib -L.libs .. then. Call for help: I need access to an OpenBSD box or someone with access to help me debug this (off-list), because the failure is not exposed with GNU ld. Cheers, Ralf
