Bug 212520 - gcc ignores setarch
gcc ignores setarch
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-27 04:02 EDT by Hans de Goede
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-27 04:09:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-10-27 04:02:47 EDT
"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 04:09:48 EDT
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 04:14:01 EDT
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 04:27:44 EDT
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 04:32:02 EDT
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.