Bug 355551 - rpmrc provides obsolete default switches
rpmrc provides obsolete default switches
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
: Reopened
Depends On: 454887
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-27 21:07 EDT by Devrim GUNDUZ
Modified: 2009-01-20 15:48 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:48:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Devrim GUNDUZ 2007-10-27 21:07:20 EDT
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 06:41:09 EDT
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 16:54:50 EST
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 01:40:07 EST
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 10:21:03 EDT
The RPM rebase in 5.3 includes a fix for this issue.
Comment 5 RHEL Product and Program Management 2008-07-16 10:31:21 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
release.
Comment 11 errata-xmlrpc 2009-01-20 15:48:44 EST
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.