Alexander E. Patrakov wrote: > 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
I've seen a sort-of-inverse of that break (though not permanently fail) before, when the system is not multilib (64-bit only). If, when the .la file was installed, --libdir was /usr/lib, and that directory was a symlink to lib64, then libtool complains about the file having been moved because it finds it in /usr/lib64 first. But that's different than what you're describing, and I had not run into the situation you describe. That's despite having built lots and lots of libraries as both 32-bit and 64-bit (with proper --libdir args for each, doing 64-bit last to overwrite installed 32-bit binaries, and special handling of *-config scripts to look at an environment variable to decide which bit width script to execute to pick up the right flags), and having linked against them, on the system I'm currently running. Haven't ever had this happen. I *suppose* that might be because pkg-config or some equivalent fixes it up somehow, pointing to the .la files directly. Or maybe -L affects this somehow. Well that sucks. :-) Sigh. > 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? Not really. I assumed libtool handled multilib the same way gcc did. Figures that it doesn't. :-/ Argh. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
