Bug 212520 - gcc ignores setarch
Summary: gcc ignores setarch
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-27 08:02 UTC by Hans de Goede
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2006-10-27 08:09:48 UTC

Attachments (Terms of Use)

Description Hans de Goede 2006-10-27 08:02:47 UTC
"gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64
system as expected however, "setarch i386 gcc -o hello helloworld.c"
also creates an x86_64 elf file instead of an i386 one, to get an i386
one I must do: "gcc -m32 -o hello helloworld.c".

This is unfortunate, because even though rpmbuild adds -m32 to the
*FLAGS environment variables compiling i386 packages on an x86_64 system still
doesn't work for many packages, because they for example often ignore LDFLAGS,
thus not specifying -m32 when linking, causing things to fail. This is one of
the last problems building i386 binaries on an x86_64 system and should really
be fixed now that most of the work has already been done by making x86_64 and
i386 -devel packages parallel installable.

A work around is to create shell script wrappers for gcc, g++ and ld
which always add -m32, put these somewhere outside the standard $PATH
and add the location to PATH when you want to build i386 binaries.

Comment 1 Jakub Jelinek 2006-10-27 08:09:48 UTC
That's intentional, you really should use proper CFLAGS and LDFLAGS.
Basing -m32/-m64 default based on environment would be very confusing e.g.
when reporting bugs, would make reproducibility more difficult. Propagating
$RPM_OPT_FLAGS down to all C*FLAGS is desirable for many other reasons, e.g.
buffer overflow protection etc.

Comment 2 Hans de Goede 2006-10-27 08:14:01 UTC
I already was afraid this was going to get closed in this way and I understand,
however fixing all circa 3000 packages in FE + FC for this is not really doable.

Well I guess I'll just keep using the shell wrappers in dir not normally in PATH
and add dir to PATH when building i386 binaries approach then.

Comment 3 Jakub Jelinek 2006-10-27 08:27:44 UTC
It is doable and very much desirable, we really shouldn't be unintentionally
shipping programs built without -D_FORTIFY_SOURCE=2, -fstack-protector etc.
I'm not aware of anything in FC that doesn't honor these unless it has a reason
for it (e.g. in glibc and gcc itself), if you know about anything, feel free
to file a bugreport.

Comment 4 Hans de Goede 2006-10-27 08:32:02 UTC
The problem isn't as much in CFLAGS as it is in LDFLAGS, I maintain 80 packages
in FE and where nescesarry have patched them to honor RPM_OPT_FLAGS during the
compile fase, but I've been doing some experimenting with building i386 only
packages (lots of asm bah) on x86_64 and on many cases LDFLAGS doesn't get
properly propegated.

I fully agree with you that RPM_OPT_FLAGS should always be used.

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