Lots of fun last night and this morning. 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking.
Case in point: libdns/ldns. It does link with libtool link cc -o somelib --export-symbols lib.def someobj.o notice the --export-symbols, that's not a valid gnu libtool option (the option is spelled -export-symbols). So it gets ignored ! this did work by accident for us, since we used Getopt::Long which doesn't care if it's --export-symbols or -export-symbols... when I fixed that, suddenly, we got some different behavior, so our link stopped working. But I'll contend that's a fucking BUG in gnu libtool, since you can just mispell something, and hey, watch it ! magic trick! it's gone !!! (that also explains why some ports require gnu libtool... linking with libtool link cc -o prog a.o a.c will work with gnu libtool... yeah, I kid you not !) 2/ we had some bugs with variable mispelling for weeks... turns out some stuff to check for standard library paths was totally broken. So I fixed it, and so it broke libtool, because there's some other bug that means that we don't look where we should. More precisely -L/usr/X11/lib -lX11 will bring in -lxcb... and that's it ! but -lxcb *in turn* needs to bring in pthread-stubs Xau and Xdmcp All live under /usr/X11R6/lib... and the linker complains. So I "fixed" that by adding -rpath-link for standard directories, and -rpath for non-standard directories... The deeper bug being that we do not look inside xcb for further paths, which is probably what needs to happen. Well, at least libtool builds should no longer include rpaths for /usr/local/lib and /usr/X11R6/lib...
