Niels Thykier <[email protected]> writes: > ? shlib-calls-exit > - There was some disagreement here, but it seems to have ended in favor > of keeping the tag. Possibly with whitelisting some known cases, e.g. > Apache modules?
I further investigated the Apache issue, and I see no sign of any other facility provided to handle a missing but required configuration directive, which was the specific case that I ran into. There are mechanisms to handle a syntax error in a directive that is provided, but once the configuration has been parsed, the after-config hook has no way of returning a fatal error to Apache. That said, this is an edge case that other Apache modules appear to address by just not having any required Apache directives (instead, the module is just deactivated with loud warnings if the directives aren't present). I will take that approach upstream when I get a chance; in the meantime, I can just override this tag for Apache modules. That does leave the problem that libtool convenience libraries that are used for both command-line programs (where fatal error reporting is desirable) and shared libraries (where it isn't, but the shared library never calls the relevant function) will trigger false positives for this tag. This affects basically every shared library for which I'm upstream, so it's kind of annoying. The ideal, of course, would be for the linker to be smart enough to strip the unused entry point from the convenience library when it is merged with the shared library, but it alas isn't smart enough to do that even if the fatal error entry point is isolated to its own *.o file that is completely unused by the shared library. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
