Bug 199359 - PATCH: sparc64 use CFLAGS
Summary: PATCH: sparc64 use CFLAGS
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-obsolete   
(Show other bugs)
Version: rawhide
Hardware: sparc64
OS: Linux
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-19 03:11 UTC by Dennis Gilmore
Modified: 2007-11-30 22:11 UTC (History)
8 users (show)

Fixed In Version: 1.02.14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-11 16:26:25 UTC
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-19 03:11 UTC, Dennis Gilmore
no flags Details | Diff

Description Dennis Gilmore 2006-07-19 03:11:57 UTC
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-19 03:11:57 UTC
Created attachment 132639 [details]
use cflags

Comment 2 Milan Broz 2007-01-02 10:13:32 UTC
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 12:45:31 UTC
Yes on aurora  gcc-4.1.1 

did you compile 32 or 64 bit?

Comment 4 Milan Broz 2007-01-02 13:37:50 UTC
32bit/gcc 3.4.6

You are compiling it in for 64bit userspace ?

Comment 5 Dennis Gilmore 2007-01-02 13:40:25 UTC
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 16:27:23 UTC
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 05:13:53 UTC
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 13:16:58 UTC
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 13:56:32 UTC
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 16:26:25 UTC
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.