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?
*** This bug has been marked as a duplicate of 126853 ***
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.
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.
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).
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.
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