Description of problem: Somewhere along the line libxml2 stopped building using gcc4. According to Daniel the errors gcc is complaining about should just be warnings, but maybe this is intended behaviour and needs to be worked around in libxml2? Output is like this: gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g -O2 -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -MT SAX.lo -MD -MP -MF .deps/SAX.Tpo -c SAX.c -fPIC -DPIC -o .libs/SAX.o elfgcchack.h:61: error: '__xmlGenericError' aliased to undefined symbol '__xmlGenericError__internal_alias' elfgcchack.h:65: error: '__xmlGenericErrorContext' aliased to undefined symbol '__xmlGenericErrorContext__internal_alias' ... elfgcchack.h:7840: error: 'xmlXPtrWrapLocationSet' aliased to undefined symbol ' xmlXPtrWrapLocationSet__internal_alias' make[2]: *** [SAX.lo] Error 1 make[2]: Leaving directory `/home/kmaraas/cvs/gnome/libxml2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kmaraas/cvs/gnome/libxml2' make: *** [all] Error 2 [kmaraas@localhost libxml2]$ Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Until a few days ago it was just a warning, but now it is a hard error. See http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01581.html and following thread for details. The only known way how to get the useful protected semantics is ATM the 2 macro approach glibc uses (one macro on the prototype (or below the prototype, but before its uses), one macro below function/variable definition.
Okay, that would need complete changes of the full libxml2 code base instead of a single autogenerated header. I will remove the whole optimization as a result. Lot of wasted time from me an arjan on this :-( too bad, libxml2 on gcc4 will be slower and bigger than on gcc3. But code maintainance is more important, I will not pollute all the C file with custom macros to work around compilers or format lack of optimization. Daniel
libxml2-2.6.19 includes a new generation of elfgcchack.h which tries to preserve the optimization, I still had to modify all C files but it is only 2 lines added at the end of each module. I hope the semantic/behaviour of the gcc extensions won't change again. The main feedback I got around the community was "why bother with compiler specific extensions ?" The new version is in Rawhide. Daniel