Debugging 32-bit applications on an x86_64 system
siddhesh.poyarekar at gmail.com
Sat Jun 19 08:01:20 UTC 2010
On Sat, Jun 19, 2010 at 1:16 PM, Jonathan Ryshpan <jonrysh at pacbell.net> wrote:
>> You could download the debuginfo rpm, decompress it using rpm2cpio and
>> the load up the program with LD_LIBRARY_PATH pointing to the location
>> where you decompressed it.
> Again, this would be tedious, since there are 33 debuginfo packages that
> need to be loaded.
Agreed. Btw, I don't really think you need all debuginfo packages to
debug a google earth crash unless you're sure that the problem is not
in google earth itself. I assume you're confident of that, which is
why you're looking for clues in the OS instead.
>> And you also ought to be reporting this as a bug, since ideally the
>> package should be split up to separate xmlwf from expat. Maybe
>> discussion on the fedora devel list would make this clearer:
> This is not a particular bug, but rather a *kind* of bug. I don't think
> all 33 packages have this problem, but enough of them do to create a lot
> of trouble. In fact none of the 33 debuginfo packages would load.
Yes, but the only way to get this fixed this is to find and report
bugs for them. Binaries and libraries (especially ones that are
distributed to be linked against) do not belong in the same package.
> I assume you are pointing to the list in general, and not to any special
Yes, the discussion would be very fruitful on devel list since there
would be a lot of people who would have good ideas on it; not just the
bug in question, but also alternative ways to acquire the debuginfo
packages necessary without doing the hard work.
> Indeed the *best* way forward is to eliminate proprietary packages, or
> (at least) to have proprietary code released in source form for Linux
> only, as (I think) qt and ghostscript are. Then getting 64-bit packages
> requires not too much more than recompilation.
> But lets not hold our breath. The open source driver (nouveau) for my
> video card (Nvidia GeForce 9500 GT) does not utilize the full capacity
> of the card; the proprietary driver (kmod-nvidia) is broken, and causes
> Google Earth (yet another proprietary program, which I'm very fond of)
> to crash on startup. The open source Flash plugin for Firefox has been
> under development for years, and still doesn't display many (most?)
> Flash URLs. The proprietary Flash plugin (64-bit) makes Firefox crash
> on termination.
> The suggestion gives maybe the best way forward under the circumstances.
I'm not talking about elimination of multilib support (32 bit
libraries on x86_64). I was actually talking about the expat package
(or similar packages), and that 32 bit binaries should not be
distributed on x86_64 as part of the distribution.
More information about the users