Bug 150115 - libxml2 build breaks with gcc4 on s390
libxml2 build breaks with gcc4 on s390
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
s390 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2005-03-02 11:40 EST by Daniel Veillard
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 4.0.0-0.33
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-11 19:13:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Logs from the build (224.05 KB, text/plain)
2005-03-02 11:50 EST, Daniel Veillard
no flags Details
the output of gcc4 failure on xpointer on ia64 (665.76 KB, text/plain)
2005-03-04 08:24 EST, Daniel Veillard
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 20249 None None None Never

  None (edit)
Description Daniel Veillard 2005-03-02 11:40:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041215 Firefox/1.0 Red Hat/1.0-12.EL4

Description of problem:
rebuilding libxml2 in beehive broke.
First I get tons of aliasing warnings.
Then the compile stops with an exit code 1 by gcc4 on the schemas.c
file, while showing only warnings.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
I tried to rebuild twice failed twice

1.rebuild libxml2-2.6.17 on s390

Actual Results:  spits thousands and thousands of warnings 
dies in the xmlschemas,c module

Expected Results:  compile or at least emit an error why it could not

Additional info:
Comment 1 Daniel Veillard 2005-03-02 11:51:00 EST
Created attachment 111581 [details]
Logs from the build
Comment 2 Daniel Veillard 2005-03-02 11:53:06 EST
Libxml2 code seems to compile fine with gcc4-4.0.0-0.22 on i686,

Comment 3 Matthias Clasen 2005-03-03 07:53:39 EST
FWIW, this problem also affects glib2 and gtk2, which also use
a PLT-reduction technique based on aliasing.
Comment 4 Alexandre Oliva 2005-03-03 16:42:33 EST
Any chance you could try a rebuild with -no-suppress in the flags
passed to libtool ... gcc?  This will drop the redirection of the PIC
compile error output to /dev/null, and will at least let us hazard a
guess as to the actual problem.
Comment 5 Daniel Veillard 2005-03-03 17:32:37 EST
Sorry I really don't know libtool, I have no idea how to influence

Comment 6 Alexandre Oliva 2005-03-03 20:42:23 EST
Ok, I managed to duplicate the error.  It's the profile generation
option that's triggering the bug.  You may want to temporarily disable
that to get a successful rebuild.

As for knowing or not knowing libtool, whether you do is irrelevant to
my request.  I only suggested you to adjust the build machinery of
your package (which presumably you're familiar with) to pass an
additional flag to the libtool compiler combo when compiling this
particular file.  Your reply is similar to `I don't know compilers, so
I can't pass flags to them'.  I.e., I was not asking you to modify
libtool or do anything with it, only pass whatever flags to it that
you already pass, plus this one flag I suggested.
Comment 7 Daniel Veillard 2005-03-04 08:14:38 EST
Got this on ia64 without removing the profile generation yet,
it is on a different file than where it failed on s390:

xpointer.c: In function 'xmlXPtrLocationSetRemove__internal_alias':
xpointer.c:760: internal compiler error: in simplify_subreg, at
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/cchIZg04.out file, please attach
this to your bugreport.

w.r.t. to your request, I never invoke libtool directly myself.
I am not familiar with the auto* machinery, and have no idea how
  1/ to pass libtool flags
  2/ that -no-suppress is a valid libtool flag
I use AM_PROG_LIBTOOL in configure.in, and have no idea what's going
on behind it. Here is my level of knowledge on libtool:

paphio:~/XML -> grep -i libtool configure.in Makefile.am
paphio:~/XML -> man libtool
No manual entry for libtool
paphio:~/XML -> man automake
No manual entry for automake
paphio:~/XML ->

  it's a black box to me, not just libtool, the whole build, and
getting things fixed in it is purely a modify-try-fail-retry 
process whitout any understanding of the beast. Sad but true,
I control my code, but not the build.

Comment 8 Daniel Veillard 2005-03-04 08:24:44 EST
Created attachment 111660 [details]
the output of gcc4 failure on xpointer on ia64
Comment 9 Jakub Jelinek 2005-03-10 04:13:29 EST
The s390 -fprofile-use bug has been fixed upstream and will make it into
-0.33 soon.
I'll look at the ia64 ICE.
Comment 10 Daniel Veillard 2005-03-10 04:23:18 EST
Okay, fixes on libxml2 side have been integrated in upstream,

Comment 11 Jakub Jelinek 2005-03-10 11:33:30 EST
The IA64 ICE is PR20249.
Comment 12 Jakub Jelinek 2005-03-11 19:13:51 EST
Both the s390 and ia64 -fprofile-{generate,use} bugs should be fixed in
Comment 13 Daniel Veillard 2005-03-11 19:20:45 EST
Okay I will have to regenerate libxml2 packages, probably over the
week-end, then I will be able to give comparative performances figures
that arjan asked :-)

  thanks !


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