New in gettext 0.15, there is supposedly support for libexpat.so.1 rather than libexpat.so.0. But this is broken on OS's for which gettext uses dlopen(), namely Linux. `strings /usr/bin/xgettext | grep expat` will return libexpat.so.0 rather than libexpat.so.1. This originates in gettext-0.15/gettext-tools/src/x-glade.c. When using dlopen(), XML_MAJOR_VERSION never gets defined, so the code defaults to using libexpat.so.0 rather than libexpat.so.1. Really it should be smart enough to try either at runtime, but it should at least get fixed to use XML_MAJOR_VERSION. Just adding an #include <expat.h> in the appropriate section was not enough, as that caused other conflicting definitions.
(Just plonking a note here, for reference: dev-libs/expat-1.x generates libexpat.so.0, with XML_MAJOR_VERSION = 1 dev-libs/expat-2.x generates libexpat.so.1, with XML_MAJOR_VERSION = 2) x-glade.c is manually defining the interface when it uses dlopen() in place of including <expat.h>, so clearly including <expat.h> isn't what the author intended - although I don't see why it's done that way. XML_MAJOR_VERSION is only defined in expat.h; my guess is that in gettext it should have been defined by a configure check which detects which version of libexpat is installed. Assuming this is the case, we will would have to force a rebuild of gettext whenever expat is upgraded from .0 to .1. The other way of getting around it is to slot dev-libs/libexpat (with dev-libs/expat-2.0.0 at SLOT="1").
(In reply to comment #1) > x-glade.c is manually defining the interface when it uses dlopen() in place of > including <expat.h>, so clearly including <expat.h> isn't what the author > intended - although I don't see why it's done that way. XML_MAJOR_VERSION is > only defined in expat.h; my guess is that in gettext it should have been > defined by a configure check which detects which version of libexpat is > installed. I proposed this solution to upstream but received no answer. > Assuming this is the case, we will would have to force a rebuild of gettext > whenever expat is upgraded from .0 to .1. The other way of getting around it > is to slot dev-libs/libexpat (with dev-libs/expat-2.0.0 at SLOT="1"). configure.ac forces the dl* interface for expat on linux, while on every other system it uses standard linking; we can patch it to use the latter also on linux. Alternatively, as proposed by Donnie, we can modify x-glade.c to always load libexpat.so.1 and depend on expat-2.
Created attachment 96054 [details, diff] patch to not use dlopen to load expat on linux
feel free to do whichever you think is best Emanuele ;)
Opting for slotted solution would probably be best solution as too many thing could otherwise break? Regardin latter please also look at bug #128108.
This appears to affect other packages as well. After emerging dev-libs/expat-2.0.0, emerging sys-apps/kbd and sys-apps-net-tools failed as described above. After I went back to dev-libs/expat-1.95.8, these packages emerge without error. Perhaps it be a good idea to add >=dev-libs/expat-2.0.0 to the mask file until you decide to slot or not.
gettext-0.15-r1 has this fix, just forgot to close this bug
