Bug 327641 - in devel gcc-compat-34 fails to build a program which works OK in F7
Summary: in devel gcc-compat-34 fails to build a program which works OK in F7
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: compat-gcc-34
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-11 13:27 UTC by manuel wolfshant
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-10-15 07:40:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
failed build log (devel, x86_64) (12.71 KB, text/plain)
2007-10-11 13:27 UTC, manuel wolfshant
no flags Details
A small test case (251 bytes, text/plain)
2007-10-11 13:34 UTC, Nils Philippsen
no flags Details

Description manuel wolfshant 2007-10-11 13:27:53 UTC
Description of problem:
compilation of a file from the trickle package fails because gcc34 bails out with:

gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c trickled.c
trickled.c: In function `trickled_setup':
/usr/include/bits/string3.h:79: sorry, unimplemented: inlining failed in call to
'memset': recursive inlining
trickled.c:84: sorry, unimplemented: called from here

The same C source can be compiled OK with gcc-compat-34 included in F7.

Version-Release number of selected component (if applicable):
 compat-gcc-34           x86_64     3.4.6-7  

How reproducible:
always

Steps to Reproduce:
1. try to build http://wolfy.fedorapeople.org/trickle-1.07-1.fc7.src.rpm
2. watch it fail
  
Actual results:
build fails, as seen at
http://koji.fedoraproject.org/koji/getfile?taskID=191187&name=build.log

or in short:

+ /usr/bin/make
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c trickle.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c util.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c getopt.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c strlcat.c
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c strlcpy.c
/bin/sh ./libtool --mode=link gcc34 -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64  -o trickle  trickle.o
util.o getopt.o strlcat.o strlcpy.o -lnsl  -ldl
mkdir .libs
gcc34 -Wall -Icompat -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-m64 -o trickle trickle.o util.o getopt.o strlcat.o strlcpy.o  -L/usr/lib64
-lnsl -ldl
gcc34 -DHAVE_CONFIG_H -I. -I. -I.    -Wall -Icompat  -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64  -L/usr/lib64 -c trickled.c
trickled.c: In function `trickled_setup':
/usr/include/bits/string3.h:79: sorry, unimplemented: inlining failed in call to
'memset': recursive inlining
trickled.c:84: sorry, unimplemented: called from here
make: *** [trickled.o] Error 1

Expected results:
program should build successfully, as seen at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=191178

Additional info:

Comment 1 manuel wolfshant 2007-10-11 13:27:53 UTC
Created attachment 224271 [details]
failed build log (devel, x86_64)

Comment 2 Nils Philippsen 2007-10-11 13:34:06 UTC
Created attachment 224281 [details]
A small test case

Compile the attached testcase with the following command:

gcc34 -O2 -Wp,-D_FORTIFY_SOURCE=2 gcc34_memset.c -o gcc34_memset

Comment 3 Jakub Jelinek 2007-10-11 13:47:47 UTC
Why do you use gcc34 to build the package?
Appart from buggy configure* which checks for in_addr_t in a wrong header
it compiles just fine.

Comment 4 Nils Philippsen 2007-10-11 15:11:27 UTC
(In reply to comment #3)
> Why do you use gcc34 to build the package?
> Appart from buggy configure* which checks for in_addr_t in a wrong header
> it compiles just fine.

I've addressed that one already. Still, gcc34 doesn't like memset() if used with
the options mentioned in comment #2 -- either this should work or mentioned
somewhere with a big "don't do that", perhaps in the release notes?

Comment 5 manuel wolfshant 2007-10-11 18:11:31 UTC
I am using gcc34 for the simple reason that it accepts the source file(s)
unmodified. And the resulting binary works as advertised.

Nils kindly provided a fix and I have also located an ugly hack which allow
usage of gcc4. However the problem I see here is gcc34 failing (under certain
circumstances) in F8 (but not in F7).


Comment 6 Jakub Jelinek 2007-10-15 07:40:57 UTC
The extremely limited fortification support in gcc34 could only work with
macros (which were used in bits/string3.h and bits/stdio2.h, but no other
fortification headers), now that we use inlines everywhere it can't work at all.
I have turned off fortification support for gcc < 4.1 altogether, with a warning.
That said, except for qemu nothing in F8 should be compiled with the
compat compilers, so please don't even think of that as an alternative.


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