[systemd-devel] [PATCH 3/6] nss-myhostname: integrate into systemd buildsystem

[Alexander E. Patrakov]

2013/1/7 Bryan Kadzban <bryan at 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