Bug 152425 - gcc4 fails to build libxml2
Summary: gcc4 fails to build libxml2
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-29 13:23 UTC by Kjartan Maraas
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-29 14:49:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Kjartan Maraas 2005-03-29 13:23:07 UTC
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
elfgcchack.h:61: error: '__xmlGenericError' aliased to undefined symbol
elfgcchack.h:65: error: '__xmlGenericErrorContext' aliased to undefined symbol


elfgcchack.h:7840: error: 'xmlXPtrWrapLocationSet' aliased to undefined symbol '
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:
Actual results:

Expected results:

Additional info:

Comment 1 Jakub Jelinek 2005-03-29 14:49:37 UTC
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.

Comment 2 Daniel Veillard 2005-03-29 15:49:44 UTC
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.


Comment 3 Daniel Veillard 2005-04-04 09:50:54 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.