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
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
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.