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. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
