Bug 150115

Summary: libxml2 build breaks with gcc4 on s390
Product: [Fedora] Fedora Reporter: Daniel Veillard <veillard>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: mclasen, oliva
Target Milestone: ---   
Target Release: ---   
Hardware: s390   
OS: Linux   
Whiteboard:
Fixed In Version: 4.0.0-0.33 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-12 00:13:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Logs from the build
none
the output of gcc4 failure on xpointer on ia64 none

Description Daniel Veillard 2005-03-02 16:40:01 UTC
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):
gcc-4.0.0-0.30

How reproducible:
Always

Steps to Reproduce:
I tried to rebuild twice failed twice

1.rebuild libxml2-2.6.17 on s390
2.
3.
    

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
compile

Additional info:

Comment 1 Daniel Veillard 2005-03-02 16:51:00 UTC
Created attachment 111581 [details]
Logs from the build

Comment 2 Daniel Veillard 2005-03-02 16:53:06 UTC
Libxml2 code seems to compile fine with gcc4-4.0.0-0.22 on i686,

Daniel

Comment 3 Matthias Clasen 2005-03-03 12:53:39 UTC
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 21:42:33 UTC
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 22:32:37 UTC
Sorry I really don't know libtool, I have no idea how to influence
this.

Daniel

Comment 6 Alexandre Oliva 2005-03-04 01:42:23 UTC
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 13:14:38 UTC
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
simplify-rtx.c:3674
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
configure.in:AC_LIBTOOL_WIN32_DLL
configure.in:AM_PROG_LIBTOOL
configure.in:XML_LIBTOOLLIBS="libxml2.la"
configure.in:AC_SUBST(XML_LIBTOOLLIBS)
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.

Daniel

Comment 8 Daniel Veillard 2005-03-04 13:24:44 UTC
Created attachment 111660 [details]
the output of gcc4 failure on xpointer on ia64

Comment 9 Jakub Jelinek 2005-03-10 09:13:29 UTC
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 09:23:18 UTC
Okay, fixes on libxml2 side have been integrated in upstream,
 thanks

Daniel

Comment 11 Jakub Jelinek 2005-03-10 16:33:30 UTC
The IA64 ICE is PR20249.

Comment 12 Jakub Jelinek 2005-03-12 00:13:51 UTC
Both the s390 and ia64 -fprofile-{generate,use} bugs should be fixed in
gcc-4.0.0-0.33.

Comment 13 Daniel Veillard 2005-03-12 00:20:45 UTC
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 !

Daniel