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.

3 thoughts on “Some more useful information about –as-needed

  1. Hey Diego. What’s the best way to get up to speed on autotools in general? I know there are some books out there (including autobook which i actually maintain but never got around to reading all the way through ;P), but most are dated and don’t really reflect best practices in the real world. I find this stuff pretty interesting but have never been able to find a good source of information.I guess I should bite the bullet and brave the info pages (god how i hate info).

    Like

  2. the autoconf manual in the gnu website is quite nice and m4sugar usually let you avoid common pitfalls. I hadn’t found anything as useful for autotools.

    Like

  3. Is there any bug with –as-needed which doesn’t require undefined behaviour to trigger? The common example of a plugin which registers itself by static constructor requires the registry to be constructed first. The order of static constructor execution IS undefined…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s