On 25 Nov 2009, Daniel P. Berrange spake thusly:
> On Mon, Nov 23, 2009 at 09:28:24PM +0000, Nix wrote:
>> If libraries go in $LDFLAGS while AC_CHECK_LIBbing, they'll end up in
>> front of the object file name, which rarely works well. They belong
>> in $LIBS.
>
> What platforms / scenarios show this problem ? Empirically it has
> been working fine on our commonly tested platforms, so it'll be
> important to know where to look/test for this problem.
Autoconf has always sorted $LDFLAGS before object files. When
-Wl,--as-needed is turned on by default (as a number of distros do),
such libraries are silently dropped because nothing needs symbols from
them at that point in the link, just as if they were static
libraries. Without -Wl,--as-needed, every single library named in the
link is added to DT_NEEDED, so this works.
Nonetheless, it is plainly obvious to any Unix hand that
cc -L/usr/lib -lfoo -o test thing-that-uses-foo.o
is less likely to work than
cc -L/usr/lib -o test thing-that-uses-foo.o -lfoo
and if you put libraries in LDFLAGS, the former's often what you get.
It'll probably fail for you, too, if HAL (say) is statically linked,
because the -Wl,--as-needed behaviour for shared libraries is exactly
how static libraries have always worked.
The GNU Autoconf manual has long stated
-- Variable: LDFLAGS
[...]
Don't use this variable to pass library names (`-l') to the
linker; use `LIBS' instead.
(I'm surprised that no Gentooers, for instance, have reported this
already. A *lot* of distros turn on -Wl,--as-needed by default these
days, often by modifying the built-in GCC specs and providing a fallback
specs file that specifies -Wl,--no-as-needed for those very rare things,
such as glibc's testsuite, that actually *require* linkage with shared
libraries from which no symbols are required.)
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list