[xml/sgml-pkgs] Bug#521994: Bug#521994: Bug#521924: wx2.6-headers: Cause compiler errors with glibc 2.9

Ron ron at debian.org
Tue Mar 31 10:18:21 UTC 2009

On Tue, Mar 31, 2009 at 07:36:10AM +0200, Mike Hommey wrote:
> I don't see how libxml2 is affected here... If protects the
> ATTRIBUTE_PRINTF definition in a #ifndef.

Right, and the wx guys thought _they_ had it protected in exactly
the same way.  But that doesn't save either of them from the symbol
conflict, it just means they'll 'accept' any random definition from
someone else if they didn't get in first.

The detailed answer to that is here:
> > > See wx/defs.h around line 483 for why that would Go Badly.

But the summary is neither of these packages should be exporting a
macro with such a generic name, and they almost certainly conflict on
what it should be defined as.  The wx 'unicode' builds (which we use)
expect all string literals are wchar_t, and since the format checking
doesn't work with those, this must be defined empty else code will
fail to compile.  (that's not precisely how this first failed, but it's
how it will fail next if we try to kludge around this without actually
resolving the namespace pollution/conflict)

So if you include wx first, you'll inadvertently disable this check
for libxml, and if you include libxml first, it will cause 'unicode'
wx apps to ftbfs, for at least two reasons I can see at a quick glance.
Not really what I'd call desirable behaviour from library headers.

Since neither wx nor libxml really _should_ be exporting this, but both
actually need it when the header prototypes are read, both should mangle
it to a more pseudo-private namespace where clashes are less likely.
It's probably 'too late' to do that for wx2.6 now, but it definitely
should be done for wx2.8+, and since it seems like a new addition to
libxml, and there's been a proven conflict already, it seems pointless
to question which package has priority over a non-standard symbol
being put to non-standard uses, both should just move it into their
own namespaces and leave some room for the next guy to screw this up
for a while.


More information about the debian-xml-sgml-pkgs mailing list