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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 132639 [details] use cflags
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?
32bit/gcc 3.4.6 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)