Bug 171391 - macros like %_lib don't reflect --target
macros like %_lib don't reflect --target
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
Blocks: 176344
  Show dependency treegraph
Reported: 2005-10-21 09:42 EDT by Göran Uddeborg
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-07 08:55:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Göran Uddeborg 2005-10-21 09:42:22 EDT
Description of problem:
The target flag affects some RPM macros, like %optflags.  Others, in particular
%_lib, still have their x86_64 definition (lib64 rather than lib in the case of

Version-Release number of selected component (if applicable):
rpm-4.3.3-11_nonptl redhat-rpm-config-

How reproducible:
Every time.

Steps to Reproduce:
1.Build any package on an x86_64, using --target=i386

Actual results:
Anything using %_libdir will point to /usr/lib64

Expected results:
%_libdir should point to /usr/lib
Comment 1 Paul Nasrat 2005-10-25 11:37:43 EDT
Out of curiosity if you 

mv /etc/rpm/platform /etc/rpm/platform.old

and retry does the desired behaviour occur?
Comment 2 Göran Uddeborg 2005-10-26 04:28:32 EDT
No, removing the platform file didn't change anything.  %optflags still works
and %_lib still doesn't.
Comment 3 Paul Nasrat 2005-11-30 13:25:50 EST
Applies to ppc64  ( and sparc 64 too for Aurora).
Comment 10 Johnny Hughes 2006-05-08 11:02:38 EDT
how about using:

setarch=i386 {rpmbuild command} --target i386
Comment 11 Johnny Hughes 2006-05-08 11:04:29 EDT
oops I meant

setarch i386 {rpmbuild command} --target i386
Comment 12 Göran Uddeborg 2006-05-08 16:10:34 EDT
Even with setarch, %_libdir still is /lib/lib64.  At least for me.
Comment 13 Tom "spot" Callaway 2006-05-24 10:47:10 EDT
On Aurora, using sparc32/sparc64 and removing /etc/rpm/platform entirely is a
valid workaround.
Comment 14 Jeff Johnson 2006-08-06 17:43:03 EDT
This problem is likely fixed (by setting arch from --target) in rpm-4.4.7-0.15

Comment 16 RHEL Product and Program Management 2006-08-18 13:12:55 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 18 Dennis Gilmore 2006-09-11 21:59:40 EDT
when was this closed WONTFIX and what is the explanation for it?
Comment 19 Kostas Georgiou 2006-09-12 04:41:03 EDT
Paul Nasrat 2006-09-07 08:55 EST Resolution WONTFIX

As for the explanation who knows... 
Comment 21 Paul Nasrat 2006-09-12 08:26:33 EDT
Dennis - the WONTFIX state is to indicate this will not be done for an update
release for RHEL 4.  I am following the Red Hat bug state process for setting
this state. You should be dealing with support/IT for escalation as an RFE for
future product releases and not directly in bugzilla.  Support engineers are
aware of the content process update and should communicate with you the reasonig.

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