Bug 171391 - macros like %_lib don't reflect --target
Summary: macros like %_lib don't reflect --target
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 176344
TreeView+ depends on / blocked
 
Reported: 2005-10-21 13:42 UTC by Göran Uddeborg
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-09-07 12:55:31 UTC


Attachments (Terms of Use)

Description Göran Uddeborg 2005-10-21 13:42:22 UTC
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
%_lib).

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

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 15:37:43 UTC
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 08:28:32 UTC
No, removing the platform file didn't change anything.  %optflags still works
and %_lib still doesn't.

Comment 3 Paul Nasrat 2005-11-30 18:25:50 UTC
Applies to ppc64  ( and sparc 64 too for Aurora).

Comment 10 Johnny Hughes 2006-05-08 15:02:38 UTC
how about using:

setarch=i386 {rpmbuild command} --target i386

Comment 11 Johnny Hughes 2006-05-08 15:04:29 UTC
oops I meant

setarch i386 {rpmbuild command} --target i386

Comment 12 Göran Uddeborg 2006-05-08 20:10:34 UTC
Even with setarch, %_libdir still is /lib/lib64.  At least for me.

Comment 13 Tom "spot" Callaway 2006-05-24 14:47:10 UTC
On Aurora, using sparc32/sparc64 and removing /etc/rpm/platform entirely is a
valid workaround.

Comment 14 Jeff Johnson 2006-08-06 21:43:03 UTC
This problem is likely fixed (by setting arch from --target) in rpm-4.4.7-0.15

UPSTREAM

Comment 16 RHEL Product and Program Management 2006-08-18 17:12:55 UTC
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
release.

Comment 18 Dennis Gilmore 2006-09-12 01:59:40 UTC
when was this closed WONTFIX and what is the explanation for it?

Comment 19 Kostas Georgiou 2006-09-12 08:41:03 UTC
Paul Nasrat 2006-09-07 08:55 EST Resolution WONTFIX

As for the explanation who knows... 

Comment 21 Paul Nasrat 2006-09-12 12:26:33 UTC
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.