Bug 355551 - rpmrc provides obsolete default switches
Summary: rpmrc provides obsolete default switches
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Panu Matilainen
QA Contact:
URL:
Whiteboard:
Depends On: 454887
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-28 01:07 UTC by Devrim GUNDUZ
Modified: 2009-01-20 20:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 20:48:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0079 0 normal SHIPPED_LIVE rpm bug fix update 2009-01-20 16:04:16 UTC

Description Devrim GUNDUZ 2007-10-28 01:07:20 UTC
Description of problem:
The rpmrc file that ships with Fedora 6-7-8 and RHEL 4 and 5 has a deprecated
switch which causes problems. The interesting issue that installing
redhat-rpm-config file fixes this issue, but it is not dependent on any packages.

I found this problem while trying to figure out why some RHEL installations were
failing to build PostgreSQL SRPM and why some do not.

Version-Release number of selected component (if applicable):

All rpm versions in RHEL 4,5 and Fedora 6-7-8-9 .

How reproducible:
Always

Steps to Reproduce:
1. remove redhat-rpm-config
2. rebuild postgresql srpm with --enable-thread-safety
3. configure fails:
=====================================================================
configure:16498: checking for the pthreads library -lpthreads
configure:16536: gcc -o conftest -O2 -g -march=i386 -mcpu=i686 -I/usr/include/et
-Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing  
-D_GNU_SOURCE  -I/usr/include   -L/usr/lib conftest.c -lpthreads  -lpam -lssl
-lcrypto -lkrb5 -lz -lreadline -ltermcap -lcrypt -ldl -lm  >&5
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
conftest.c: In function 'main':
conftest.c:138: warning: null argument where non-null required (argument 1)
conftest.c:139: warning: null argument where non-null required (argument 1)
conftest.c:139: warning: null argument where non-null required (argument 3)
conftest.c:137: warning: 'th' is used uninitialized in this function
/usr/bin/ld: cannot find -lpthreads
collect2: ld returned 1 exit status
configure:16542: $? = 1
=====================================================================

Actual results:
PostgreSQL configure script fails since -mcpu is supplied by rpmrc and it is
deprecated. 

Expected results:
Normally rpmbuild would finish successfully. 

Additional info:

There are two possible fixes for this:

1. Remove -mcpu and add -mtune or -march as suggested by gcc.
2. Add redhat-rpm-config file as a dependency for rpm-build.

I'm for (1).

Regards, Devrim

Note: Do you want me to file a bug against Fedora, too?

Comment 1 Panu Matilainen 2007-11-01 10:41:09 UTC
You need to have redhat-rpm-config installed when building packages for
RHEL/Fedora, otherwise a number of things will be wrong.

Rpm upstream configuration such as optflags are in reality totally irrelevant as
it's not rpm's business to know or dictate which version of some compiler is
used to build something.

redhat-rpm-config defines the distro-level policy/configuration for building
packages for use in RHEL/Fedora, however nothing says you can't define and use
your own configuration for other purposes. So rpm-build requiring
redhat-rpm-config would be wrong too.

This has been "fixed" in rpm upstream (and thus Fedora >= 7) by defaulting to
newer gcc flags, but actually the real fix would be to remove any such flags
from the upstream configuration, for the reasons stated above.

Comment 2 Tom Lane 2007-11-11 21:54:50 UTC
This situation doesn't seem very satisfactory to me.  It's agreed by all that you *must* have redhat-rpm-
config installed to get sane build results on Red Hat platforms.  Shouldn't we have some mechanism better 
than "expect the end user to get it right with no prompting" to enforce that?  I would normally expect the 
package require infrastructure to do this, but if neither rpm-build nor the individual SRPMs should 
Require: it (and I do see your point about why they shouldn't), what then?

Perhaps we should re-file this bug against the distribution, that is that redhat-rpm-build should be 
forcibly installed on every Red Hat configuration?  If you don't like that, then what component *should* 
take responsibility for getting this right?

Comment 3 Panu Matilainen 2007-11-12 06:40:07 UTC
I do agree it's hardly an optimal situation. "Development Tools" group contains
redhat-rpm-config, I guess that's how it typically gets installed (otherwise
we'd have many many more dupes of this :), but that doesn't help somebody who
does a base install first and then adds individual packages afterwards.

Comment 4 Denise Dumas 2008-07-16 14:21:03 UTC
The RPM rebase in 5.3 includes a fix for this issue.

Comment 5 RHEL Program Management 2008-07-16 14:31:21 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 11 errata-xmlrpc 2009-01-20 20:48:44 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0079.html


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