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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 132647 [details] use cflags
libselinux-1.30.28-1
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 here.
(In reply to comment #7) > It's ok by me, although I'm wondering what CFLAGS you are supplying that matter > here. 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.