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

Bryan Kadzban bryan at kadzban.is-a-geek.net
Mon Jan 7 20:12:17 PST 2013


Alexander E. Patrakov wrote:
> 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

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.


More information about the systemd-devel mailing list