Red Hat Bugzilla – Bug 199359
PATCH: sparc64 use CFLAGS
Last modified: 2007-11-30 17:11:38 EST
Description of problem:
sparc64 needs to use CFLAGS with CC to link properly using gcc the attached
patch fixes this issue
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 132639 [details]
Which distribution/gcc...etc did you use with this patch (Aurora?) ? I can
compile currect cvs source on sparc (Gentoo port) without problem (no patch needed).
Yes on aurora gcc-4.1.1
did you compile 32 or 64 bit?
You are compiling it in for 64bit userspace ?
its needed 64 bit to build the tool chain
it gets built both 32 bit and 64 bit
From memory 32 bit was fine 64 bit needs this patch
Please determine exactly which command line flag makes the difference.
Quote the whole gcc command line + error from the build.
Then add the flag(s) to fix it and repeat.
The issue is this:
On sparc, gcc assumes -m32. This gets translated to the appropriate sparc32 ld
flags when gcc is linking. This works fine when building applications for a
32bit sparc environment (the default) because this assumption is always correct.
However: When we're building for a 64 bit sparc64 environment (we have to build
all of the glibc/gcc dependencies as sparc64), we have to pass -m64. When gcc is
called to link the final library/binaries without passing $CFLAGS, gcc assumes
-m32, and it tries to make a 32 bit binary out of 64 bit components and explodes.
LDFLAGS is not the correct place to put -m64, nor is it worth hardcoding all of
the possible ld flags for every variant arch. By simply including $CFLAGS with
every invocation of $CC, the package builds properly in all possible cases.
So what does CFLAGS actually contain during the build, please? i.e. how does
-m64 get into it? (env?)
CFLAGS for a sparc64 build is:
-O2 -g -m64 -mcpu=ultrasparc
It picks this up from rpm macros.
OK - changed upstream and will feed into the next build.
(will do same for lvm2)