Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 199359 - PATCH: sparc64 use CFLAGS
PATCH: sparc64 use CFLAGS
Product: Fedora
Classification: Fedora
Component: device-mapper-obsolete (Show other bugs)
sparc64 Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Depends On:
  Show dependency treegraph
Reported: 2006-07-18 23:11 EDT by Dennis Gilmore
Modified: 2007-11-30 17:11 EST (History)
8 users (show)

See Also:
Fixed In Version: 1.02.14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-11 11:26:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
use cflags (1.07 KB, patch)
2006-07-18 23:11 EDT, Dennis Gilmore
no flags Details | Diff

  None (edit)
Description Dennis Gilmore 2006-07-18 23:11:57 EDT
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:
Actual results:

Expected results:

Additional info:
Comment 1 Dennis Gilmore 2006-07-18 23:11:57 EDT
Created attachment 132639 [details]
use cflags
Comment 2 Milan Broz 2007-01-02 05:13:32 EST
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).
Comment 3 Dennis Gilmore 2007-01-02 07:45:31 EST
Yes on aurora  gcc-4.1.1 

did you compile 32 or 64 bit?
Comment 4 Milan Broz 2007-01-02 08:37:50 EST
32bit/gcc 3.4.6

You are compiling it in for 64bit userspace ?

Comment 5 Dennis Gilmore 2007-01-02 08:40:25 EST
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
Comment 6 Alasdair Kergon 2007-01-10 11:27:23 EST
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.
Comment 7 Tom "spot" Callaway 2007-01-11 00:13:53 EST
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.
Comment 8 Alasdair Kergon 2007-01-11 08:16:58 EST
So what does CFLAGS actually contain during the build, please?  i.e. how does
-m64 get into it?  (env?)
Comment 9 Tom "spot" Callaway 2007-01-11 08:56:32 EST
CFLAGS for a sparc64 build is:

-O2 -g -m64 -mcpu=ultrasparc

It picks this up from rpm macros.
Comment 10 Alasdair Kergon 2007-01-11 11:26:25 EST
OK - changed upstream and will feed into the next build.
(will do same for lvm2)

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