2013/1/7 Bryan Kadzban <br...@kadzban.is-a-geek.net>: > Untrue. They're perfectly useful for dynamic linking as well: > > http://www.sourceware.org/autobook/autobook/autobook_68.html#SEC68 > > Second paragraph. Also the page several sections after this one, about > installing a shared library with libtool.
Unfortunately, on linux, libtool's la files are actively harmful for multilib setup and _must_ be removed (ideally, upstream) if possible. They represent an unsolvable problem in the following case: * you are on amd64 * libfoo is built both as 64-bit and 32-bit library and has a *.la file at least in in /usr/lib64 * you are trying to link a 32-bit program as follows: libtool --mode=compile --tag=CC gcc -m32 test.c -c -o test.lo libtool --mode=link --tag=CC gcc -m32 test.lo -lfoo -o test If /usr/lib64/libfoo.la exists, then libtool will pick it up and feed /usr/lib64/libfoo.so to gcc instead of just -lfoo. As a result, the linker will barf because of the incompatible architecture. I.e. stupid libtool duplicates the gcc library search logic, but doesn't realize that -m32 alters the library path and that the first library found may not be the one that is usable. Surely you don't want create a problem for distributions that want to build various systemd libraries both for 64 and 32 bits, do you? AFAIK RedHat works around this: https://bugzilla.redhat.com/show_bug.cgi?id=138742 but the patch has never been pushed upstream. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655450 -- Alexander E. Patrakov _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel