Thanks very much for your reply. Detailed comments follow. On Sat, 2010-06-19 at 12:48 +0530, Siddhesh Poyarekar wrote: > On Sat, Jun 19, 2010 at 1:01 AM, Jonathan Ryshpan <jonrysh@xxxxxxxxxxx> wrote: > > I'm trying to debug inspect googleearth (a 32-bit application) using gdb > > on an x86_64 system. Gdb starts OK, but when I attempt to run > > googleearth, it reports that a large number of debuginfo packages are > > missing with messages like: > > Missing separate debuginfo for /lib/libexpat.so.1 > > Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/f4/6a67411322c129b167dd758b8ab9cbd2e4ddf9.debug > > When I attempt to run yum to carry this out, yum produces error messages > > like: > > file /usr/lib/debug/usr/bin/xmlwf.debug from install of expat-debuginfo-2.0.1-10.fc13.i686 conflicts with file from package expat-debuginfo-2.0.1-10.fc13.x86_64 > > Apparently, the debug info for the *library* /lib/libexpat.so.1 is > > packaged in the same rpm with the debug info for the *executable* xmlwf. > > And since executables on x86_64 system are not segregated by execution > > model (32-bit vs. 64-bit) there is a file name conflict. > > > > (A question) Is there any way to load the debug info for these 32-bit > > library without removing the debug info for 64-bit libraries? This > > would be tedious, since there are about 100 64-bit debug packages on the > > system currently. > > 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. > 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. > https://admin.fedoraproject.org/mailman/listinfo/devel I assume you are pointing to the list in general, and not to any special discussion. > > (A suggestion) On x86_64 systems 32-bit executables and 64-bit > > executables should be in separate directories: say /usr/bin32 > > and /usr/bin/64. An addition directory /usr/bin would contain > > (symbolic) links to default executables. (I think this would keep all > > current shell scripts, etc., running.) Maybe the same file structure > > -- /usr/lib32 /usr/lib64 and /usr/lib -- would also be good for > > libraries. > > > > No, because the way forward is to eliminate the need for 32 bit > binaries on 64 bit systems. The libraries are there now because we > still have a lot of programs that are built as 32 bit only (flash). 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. Thanks again - jon -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
