Bug 130128 (IT#42221)

Summary: 64bit gdb install overwrites installed 32bit gdb
Product: Red Hat Enterprise Linux 3 Reporter: Alexandre Oliva <aoliva>
Component: gdbAssignee: Elena Zannoni <ezannoni>
Status: CLOSED ERRATA QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: cagney, jjohnstn, srevivo, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-31 15:05:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 115047    
Bug Blocks:    

Description Alexandre Oliva 2004-08-17 12:28:25 UTC
1. Install gdb-6.0post-0.20040223.17.ppc.rpm for 32bit gdb 
2. Then install gdb-6.0post-0.20040223.17.ppc64.rpm for 64bit gdb 

The 64bit gdb can be installed without a problem but it overwrites the
32bit gdb.

I suppose if you remove the 64-bit gdb, you end up without any gdb
whatsoever, even though the 32-bit gdb package is still installed.

Since 64bit gdb can handle both 32bit and 64bit applications, why do
we need to 
have 32bit gdb?  And if we do need it for any reason, why don't the
rpms conflict, instead of silently eating each other, or use some
mechanism that enables both of them to be installed, say, install
gdb32 and gdb64, and have a shared gdb script that runs gdb64 if both
are available, and the only one installed otherwise?

Comment 2 Andrew Cagney 2004-08-23 15:18:35 UTC

*** This bug has been marked as a duplicate of 126853 ***

Comment 3 Alexandre Oliva 2004-08-23 21:05:34 UTC
Questions asked by customer not answered in the other bug.  Current
resolution is not good enough in that it doesn't solve the other
related bug, listed as a dependency of this one.  Reopening.

Comment 4 Elena Zannoni 2004-08-23 23:20:33 UTC
This is the behavior of rpm, not gdb. it prefers elf64 over elf32.
Besides, the 32 bit gdb should be overwritten, since the 64 bit gdb
for ppc can debug 32 bit binaries.
But they should use a more recent gdb. Also there have been fixes to
rpm to deal with packages installing multiple binaries.
What are they running? RHEL3 U3? If so, the gdb64 package has been
obsolete. They should now just have a binary named gdb which is elf64.



Comment 5 Alexandre Oliva 2004-08-24 00:43:04 UTC
I realize the base problem is in RPM.  That's why this bug depends on
the relevant rpm bug.

The bug was originally reported against RHEL3 U2, the latest released
update for RHEL3 at this time.  It was also tested on a U3 beta
available as of June 28.

They didn't ever mention the gdb64 package.  They mentioned ppc and
ppc64 gdb packages, and that, if you install both, one of the binaries
becomes permanently inacessible.  This is a bug.  You can't, for
example, compare the behavior of a 32-bit gdb with that of a 64-bit
gdb unless you take a copy of the 32-bit gdb.

Feel free to not act on this bug at all until the dependency rpm bug
is regarded as resolved.  The current approach is far from optimal.

That said, gdb could take the lead towards a reasonable solution and
install say gdb32 and gdb64 in the 32- and 64-bit packages,
respectively, and have gdb be a hard link, such that, whatever rpm
picks up by default, both binaries will still be available (as
expected).  Hopefully rpm will eventually take such a reasonable
approach (maybe not naming the files exactly like this, but something
along these lines).

Comment 6 Elena Zannoni 2004-08-24 12:47:40 UTC
Gdb cannot take the lead, because it needs to interoperate with RHN,
up2date, rpm, and there are other requirements besides this ibm "bug".
So I am closing this yet again. Tell them to run up2date and get the
new gdb.

Comment 15 John Flanagan 2004-12-21 19:37:19 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 the 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-2004-561.html