Description of problem: Gettext can't extract messages from XML (e.g. glade) files anymore. It complains about not being built against expat which it needs to do that. Version-Release number of selected component (if applicable): nils@wombat:~> koji latest-pkg dist-f8-build gettext Build Tag Built by ---------------------------------------- -------------------- ---------------- gettext-0.16.1-9.fc8 dist-f8 petersen How reproducible: Easy. Steps to Reproduce: 1. Try to build the hwbrowser package in koji Actual results: See http://koji.fedoraproject.org/koji/getfile?taskID=155157&name=build.log : xgettext --default-domain=hwbrowser --add-comments --omit-header --keyword --keyword=_ --keyword=N_ --language=python ../DeviceDisk.py ../DeviceGeneric.py ../DeviceList.py xgettext --default-domain=hwbrowser --add-comments --omit-header -j --keyword --keyword=_ --keyword=N_ --language=Glade ../hwbrowser.glade xgettext: Language "glade" is not supported. xgettext relies on expat. This version was built without expat. make[1]: *** [hwbrowser.pot] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/hwbrowser-0.36/po' make: *** [subdirs] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.44963 (%build) Expected results: Builds flawlessly. Additional info:
I just found out that gettext links libexpat dynamically if present. In this case, the error message should explain the problem better, e.g.: Language "..." is not supported. xgettext relies on expat to do that. This version was built without expat, but would use it if it were present.
I dug a little deeper and found that xgettext tries to dynamically open libexpat.so.0 instead of libexpat.so.1 which is installed. This comes from HAVE_LIBEXPAT not being defined if the dynamic loading mechanism is used (always on Linux). This leads to expat.h not being included, therefore XML_MAJOR_VERSION not being defined. I'd suggest directly linking against libexpat so installing gettext automatically pulls in expat so the glade functionality is always a given. The direct dependency shouldn't be a problem because several other packages depend on expat already (e.g. dbus, python).
Thanks for investigating and the report. I am building (untested) gettext-0.16.1-10.fc8 which helpfully fixes this. Could you please test and see if that helps.
I suppose we could make gettext require expat too to avoid the problem of xgettext not finding it when parsing glade, but presumably most current packages would already BR expat?
(In reply to comment #3) > I am building (untested) gettext-0.16.1-10.fc8 which helpfully fixes this. > Could you please test and see if that helps. Sadly it doesn't. I've started a rebuild of gettext in a Rawhide chroot and can see that HAVE_LIBEXPAT isn't defined which prevents including the expat.h header file. (In reply to comment #4) > I suppose we could make gettext require expat too to avoid the problem > of xgettext not finding it when parsing glade, but presumably most > current packages would already BR expat? Not really, I've just now in the course of trying the hwbrowser package to build added the expat build requirement. I guess the reason why it worked before is that some basic build requirement pulls in expat. Still, I think adding an expat requirement on gettext is a good idea in addition to somehow pulling the correct library -- I guess the configure script should take care on Linux to check for expat headers and libraries being present (otherwise bail out) and define HAVE_LIBEXPAT if it opts for the dynamic loading mechanism. However you want to do it, theres a simple way to check which version it would pull, just run strings on the resulting xgettext binary this way: root@wombat:~> rpm -Uvh /tmp/gettext-0.16.1-10.fc8.x86_64.rpm Preparing... ########################################### [100%] 1:gettext ########################################### [100%] root@wombat:~> strings /usr/bin/xgettext | grep libexpat libexpat.so.0 root@wombat:~>
I've updated the patch a bit to make sure HAVE_LIBEXPAT is defined. As it's a bit urgent for me -- I want to build my packages before my vacation next week -- I'll make a test build in mock and push that to Rawhide if it works out fine and you don't object.
Created attachment 195641 [details] modified patch to correctly determine expat version
Created attachment 195661 [details] modified spec file needed to build with the modified expat patch
Seems I don't have the necessary permissions to commit. I've attached the modified expat patch and spec file (modified to run aclocal, automake, autoconf upon patching gettext-tools/configure.ac) instead. Please build as soon as you can, I want to build my packages before going away on vacation if possible.
Now that I have the permissions to commit, I've reworked my patch so that it determines the XML_MAJOR_VERSION of libexpat during build time and just defines XML_MAJOR_VERSION accordingly in config.h. gettext-0.16.1-11 is building right now which contains these changes.
Created attachment 195801 [details] patch that checks for and sets/defines XML_MAJOR_VERSION from the configure script
Created attachment 195821 [details] modified spec file
Thanks Nils for fixing and building gettext-0.16.1-11.fc8. Thanks!
This should be fixed now upstream BTW in 0.17.