Hi Jacob, * 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. Elsewhere it creates gcc -o .libs/main main.o -L/tmp/inst/lib ./.libs/liba.so \ -Wl,--rpath -Wl,/tmp/inst/lib Now please: be specific in the bug report, and state exactly which libtool version you are using (including which patches you have applied) and post all output. Also please show 'libtool --config'. I am pretty sure our testsuite covers this, too. Any failures on OpenBSD? (Please run with VERBOSE=x so one can see actually useful output.) Cheers, Ralf
run.sh
Description: Bourne shell script
