Red Hat Bugzilla – Bug 212520
gcc ignores setarch
Last modified: 2007-11-30 17:11:46 EST
"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.
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.
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.
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.
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
I fully agree with you that RPM_OPT_FLAGS should always be used.