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 attachment 157463 [details, diff] 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.
