[nut-Bugs][312617] [patch] nut-2.4.3 fails to build with LDFLAGS="-Wl,--as-needed"

[nut-bugs at alioth.debian.org]

Bugs item #312617, was changed at 2010-07-01 22:45 by Samuli Suominen
You can respond by visiting: 
https://alioth.debian.org/tracker/?func=detail&atid=411542&aid=312617&group_id=30602

Status: Open
Priority: 3
Submitted By: Samuli Suominen (ssuominen-guest)
Assigned to: Nobody (None)
Summary: [patch] nut-2.4.3 fails to build with LDFLAGS="-Wl,--as-needed" 
Category: None
Group: None
Resolution: None


Initial Comment:
Original bug is here: 

http://bugs.gentoo.org/318481

You shouldn't be using LDFLAGS to pass libraries because with LDFLAGS="-Wl,--as-needed" the linking order is wrong. The fix is cheap and simple, use LIBS instead of LDFLAGS.

You can find it attached.

----------------------------------------------------------------------

Comment By: Samuli Suominen (ssuominen-guest)
Date: 2010-07-04 21:58

Message:
I mean, the whole point of the accidental LDFLAGS to LIBS change in that one line in configure.ac was to avoid overriding LDFLAGS.
LDFLAGS="$LDFLAGS -L/path/to" will avoid that too.

----------------------------------------------------------------------

Comment By: Samuli Suominen (ssuominen-guest)
Date: 2010-07-04 21:54

Message:
It's OK to use LIBS to pass -L flags because it only defines the linking order.

Let's say LIBS is "-L/path/to -lfoo -lbar"
And LDFLAGS is "-Wl,--as-needed"

The linker ends up getting them as:

gcc -Wl,--as-needed <list of objects> -L/path/to -lfoo -lbar

Fine tuning it futher than that would just be cosmetics. :-)

And sorry about that override in configure.ac, it should have been:

LIBS="-L/usr/X11R6/lib -lgd -lpng -lz -ljpeg -lfreetype -lm -lXpm -lX11"

But because it doesn't really matter at which point -L gets passed, this will work just as fine:

LDFLAGS="$LDFLAGS -L/usr/X11R6/lib"

----------------------------------------------------------------------

Comment By: Arjen de Korte (adkorte-guest)
Date: 2010-07-04 21:40

Message:
Instead of bluntly replacing LDFLAGS with LIBS, we should carefully look at what is happening. In quite a couple of places, we will probably need to separate the output from 'pkg-config --libs' into 'pkg-config --libs-only-L' (goes into LDFLAGS) and 'pkg-config --libs-only-l' (goes into LIBS).

Furthermore, there are some packages where the distinction between LDFLAGS and LIBS is not made at all (Net-SNMP for instance, if we use netsnmp-config). I'm not sure what to do with those.

In the end, I think we have to go through all *.m4 files and add WHATEVER_LIBS where appropriate and fix up the underlying autoconf magic as well. I don't have the time for this until after the summer holidays however.

----------------------------------------------------------------------

Comment By: Charles Lepple (clepple-guest)
Date: 2010-07-04 20:05

Message:
Sorry about the bad formatting on the previous comment, but the general idea is that the search-and-replace ends up masking some LIBS= lines which seem to be needed on some platforms.

Also, the patch originally included here does not apply cleanly to the trunk (r2459).

I think we need something a little more sophisticated than just search-and-replace, though. Also, a pointer to the rationale behind --as-needed would be nice, since I thought we manually optimized the linker parameters per Debian suggestions a while back. Are there specific tools which are linked to unnecessary libraries?

----------------------------------------------------------------------

Comment By: Charles Lepple (clepple-guest)
Date: 2010-07-04 19:58

Message:
Please double-check the patch. I see a number of things like this which seem incorrect:

        dnl Initial defaults. These are only used if gdlib-config is
        dnl unusable and the user fails to pass better values in --with
        dnl arguments
        CFLAGS=""
-       LDFLAGS="-L/usr/X11R6/lib"
+       LIBS="-L/usr/X11R6/lib"
        LIBS="-lgd -lpng -lz -ljpeg -lfreetype -lm -lXpm -lX11"

In this case, the "-L/usr/X11R6/lib" is masked by the next LIBS= line. 

----------------------------------------------------------------------

You can respond by visiting: 
https://alioth.debian.org/tracker/?func=detail&atid=411542&aid=312617&group_id=30602