Bug 21219 - RFE: classify architectures where enhanced features are not build for
RFE: classify architectures where enhanced features are not build for
Status: CLOSED ERRATA
Product: Red Hat Raw Hide
Classification: Retired
Component: glibc (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-21 21:38 EST by Enrico Scholz
Modified: 2007-04-18 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-22 13:56:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2000-11-21 21:38:57 EST
At some places in glibc.spec you are checking e.g. for

%ifnarch sparcv9 i586 i686 athlon alphaev6

to disable certain parts. For people wanting to build all parts with an
optimal target, it's very annoying to search for all places such constructs
are appearing.

I would prefer the creation of a macro like

%define unwanted_archs	 sparcv9 i586 i686 athlon alphaev6

at the top of the .spec-file and its usage instead of the `%ifnarch ...'
above.
Then a full-build can be enabled easily be commenting out the
macro-definition.
Comment 1 Jakub Jelinek 2000-11-22 12:43:26 EST
IMHO you don't want to build them with anything other than the base archs,
because that just means you're no longer able to build statically linked
base arch packages (i386, alpha, sparc). And who cares about optimized
profiling library when the actual slow down caused by profiling hides any
gains.
Comment 2 Enrico Scholz 2000-11-22 13:56:11 EST
I have no need to keep compatibility with i386 (local machines are i586 and
above; to provide binaries distributed widely, there are existing special
machines). Why should I use slower settings when faster ones are existing?

I am not interested in *optimized* profiling libs, but I want profiling (&
devel) libs and I do not see any reason to compile glibc twice (once for i686,
once for i386 to get glibc-profile).

I don't want that you enable building for i686 generally, but allowing to decide
it at a *one* place  would make life easier for people (like me) who are
building their whole system for --target=i686.
Comment 3 Jakub Jelinek 2000-12-18 17:51:54 EST
See glibc-2.2-9.

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