Red Hat Bugzilla – Bug 199367
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 132647 [details]
Created attachment 158944 [details]
use cflags patch
repoening as this is present in libselinux-2.0.13-1.fc7
Steve is this acceptable upstream?
I have a patch for libsepol also. It does the same thing. Since your using
gcc to link you need to use CFLAGS to ensure that the libraries are
correctly linked always.
It's ok by me, although I'm wondering what CFLAGS you are supplying that matter
(In reply to comment #7)
> It's ok by me, although I'm wondering what CFLAGS you are supplying that matter
For multilib support, sparc needs libselinux (and libsepol) to be built as sparc
(32bit) and sparc64 (64bit). sparc builds fine (-m32 is assumed by the
compiler), but when building for sparc64, we need all compile and link
operations to have -m64 passed for it, or else gcc will mismatch (it will make
sparc64 object files, then try to link them as a 32bit library) and the build fails.
The easiest way to ensure safe and consistent builds is to universally apply
CFLAGS whenever calling CC, which is what this patch does.
This is _still_ not applied. We're going on over a year for this bug being open.
Please apply this patch, or if not, explain why?
This breaks sparc64, and we need to build libselinux (and libsepol, which has
the same failure) as sparc64 in order to build gcc.
$(LDFLAGS) is not sufficient, we need $(CFLAGS), since it invokes $(CC).
Patch was never posted to selinux list?
Red Hat bugzilla isn't the right place for upstream fixes?
Built into rawhide. Will backport in f7.
Submitted an updated patch to upstream.