Some more useful information about –as-needed

While Ciaran continues spreading the word that --as-needed is broken because it disallows some techniques that, in my opinion, are crazy enough by themselves, and wouldn’t work with Sun’s compiler or with some executable formats like Microsoft’s own PE, there are some more information about --as-needed that I’d like people to know about.

In general, with the exception of some rare, and as I said crazy, to me, designs, --as-needed is almost always fixable. The speed of the fix is usually inversely proportional to the decency of the build system.

On a standard autotools-based build system, with some exception about cyclic dependencies of modules, the problem is usually solvable in a few minutes. Usually, it’s due to libraries passed through _LDFLAGS variables instead of _LDADD or _LIBADD (depending whether the target is an executable or a library). Sometimes its caused by mistakes in the configure script though.

In particular, if you’re testing for the presence of a library, you want to pass it through the LIBS variable, rather than LDFLAGS (and remember I consider AC_CHECK_LIB harmful). For those who disagree because some software passes flags like -L through their config scripts, well, those are flags that fit perfectly in LIBS as they are libary lookup flags!

Unfortunately there are very broken build systems, like the one of xmlwrapp, that creates shared objects in ELF with no dependency, without linking any other library together and thus expecting all its users to know the list of libraries it links against (it reports a huge list of libraries through pkg-config).

In these cases, fixing the issue might require quite a lot of work. Doesn’t mean it’s impossible though, of course, just annoying, long, and boring.

To avoid introducing more issues like these, in agreement with Mike, I’ve introduced a new warning in append-ldflags, if you try to pass the -l option to link against a library, it will tell you not to do that. That’s a mistake that will cause --as-needed to fail.

Whatever I’m saying here, anyway, makes no difference on whether the designs that clash with --as-needed are sane or not. Passing libraries through LDFLAGS is a mistake, --as-needed or not, it only happens to break stuff when --as-needed is used. So let’s not put our heads under the sand and filter --as-needed directly, let’s try to fix the issue, okay?

And of course to finish, if you are unable to fix an --as-needed issue, whether you don’t have time, will, or simply think to lack the skill to fix it, let me know and I’ll do everything I can to fix the issue myself, just please don’t filter the flag up without leaving a bug open, okay? If the package is important and you want users to be able to build anyway, well, okay filter out the flag, but leave a bug open so I know it has to be fixed.

Developers seem to feel like having bugs open is a failure, instead it’s just a way to track things down. If an issue is just partly worked around, or is fixed in the wrong way, leave the bug open, maybe put it to assigned, so that you can filter it out, use the status whiteboard, whatever you want, but don’t write the bug off as FIXED, if it is not.