Adam Williamson <awilliamson@(protected):

> I might be wrong, that's why I posted my mail in the first place. But
> what I understood from the other mails on this topic is that if you get
> an error with the underlinking checks in place when building a package
> that includes a shared library, it indicates some kind of bug that
> should be fixed in the code: but if what you're building *doesn't* have
> any shared libraries, it's not a problem and you can just disable the
> checks. As I said, I might be wrong. That's why I'm asking.

well, if what you're building doesn't have any shared libraries,
--no-undefined won't bother you, --no-undefined is the default for
binaries.

--no-undefined is wrong and bothering for (some) plugins.

--no-undefined is good and useful for normal libraries.


now for liblbxutil, it seems pretty weird. Usually, if you need
--no-undefined to build a library, the binaries using that library
will need to pass the extra libraries, and it usually fail with
--as-needed. But here, lbxproxy which uses liblbxutil defines Xalloc
in di/utils.c, and so the symbol gets defined.

So it seems to be an ugly mess, and i think this is a legal use of
_disable_ld_no_undefined.