Bugzilla Bug 226931

I've made append-ldflags throw a warning when libraries are passed through it
to link them in.

The reason is that LDFLAGS should _not_ be used for libraries, as it has to be
positioned before the list of objects to link together, while libraries should
go after.

This mistake in commandline is what causes as-needed to either fail or not
apply at all (if LDFLAGS are put at the end).

Please fix your package not to pass libraries through LDFLAGS.

since there are a whole lot more packages that do this, can you please explain
how one is supposed to fix this?

if you don't care to explain your problem, then I take it as an unsolvable
problem.  sorry.

I have over 400 bugs open at the same bloody time, I'm doing my bloody job and
you can WAIT A BLOODY WEEK AT LEAST!

If the tone of the bug was less commanding and less vague, I probably could
have waited a month without a problem.

Created an attachment (id=157463) [details]
windowmaker-ldflags-libs.patch

Calm down, please, both of you. grobian, the problem is that `gcc
-Wl,--as-needed -lresolv *.o` won't link with -lresolv. It needs to be at the
end of the command line, after the .o files, so that ld can tell whether it's
actually used. This is what LIBS is for as opposed to LDFLAGS, and windowmaker
appears to have no problems with LIBS, meaning it could be fixed as simple as
this (though it'd be nice if flag-o-matic had an append-libs). Since I don't
have access to a Solaris box, could you please test to make sure that there is
no change in configure test results, and either commit this yourself or let me
know afterwards?

Aha.  Thanks for the explanation.  Looking at the thing itself, I guess I could
also just patch configure to add the right macro to figure out if resolv() can
be used without libs, or -lresolv as suggestion on Solaris.  There is such
macro, but I forget which one each time.  Wouldn't that just solve the issue in
the most elegant way?

Yes, that would be even better. It looks like windowmaker already tries to look
in libresolv:

AC_CHECK_FUNC(inet_aton, AC_DEFINE(HAVE_INET_ATON, 1, [define if you have then
inet_aton function (set by configure)]),
     for lib in resolv socket inet bsd; do
        AC_CHECK_LIB($lib, inet_aton, [AC_DEFINE(HAVE_INET_ATON)
                     NETLIBS="$NETLIBS -l$lib"; break],, $NETLIBS)
     done)

so then the question is not what the right macro is -- AC_CHECK_LIB is the
right one -- but why it didn't work.

checking for inet_aton in -lresolv... yes

so the whole -lresolv thing is obsolete (in -r7 at least)

the -lintl is left but nastier IMO.

> checking for inet_aton in -lresolv... yes
> 
> so the whole -lresolv thing is obsolete (in -r7 at least)

Good to know. I've removed it.

> the -lintl is left but nastier IMO.

There's no -lintl in the ebuilds in gentoo-x86, so I'm assuming you're checking
an overlay? Let me know and I'll take a look, in the weekend at the latest, if
you want. I'll go ahead and close this bug since it's fixed in the main tree.

> > the -lintl is left but nastier IMO.
> 
> There's no -lintl in the ebuilds in gentoo-x86, so I'm assuming you're checking
> an overlay? Let me know and I'll take a look, in the weekend at the latest, if
> you want. I'll go ahead and close this bug since it's fixed in the main tree.

Thanks, but I already found where the problem must be.  The configure script
does not properly check if it needs libintl (only if gettext function is not
found).

Anyway, it seems indeed I only fixed this for Solaris in the prefix tree, not
in gentoo-x86.