Debugging 32bit problems on multilib systems near impossible

nanonyme · n00b Joined: 20 Dec 2008 Posts: 5

I just noticed that Gentoo nowadays (2008 profiles) seems to have prebuilt library packages (emul-linux-x86) instead of having the user compile the libraries themselves. This has had several effects. Firstly all libraries are stripped and debug files aren't served as additional packages. Thus using gdb with programs that use emul-linux-x86 packages is impossible. Also the binaries are i386 so you won't get to use your own CPU's instruction sets. I would suspect this would have a performance effect in at least high-intensive programs like games run through Wine. Is there really any good side about this current multilib system?

devsk

nanonyme · n00b Joined: 20 Dec 2008 Posts: 5

Actually that's not exactly true. Wine is compiled as 32bit, it's not pre-compiled, and it also pulls in the emul stuff. Nowadays compiled programs use emul stuff too on multilib systems.

devsk · Posted: Sun Dec 21, 2008 5:15 pm Post subject:

nanonyme · n00b Joined: 20 Dec 2008 Posts: 5

Actually there used to be. Multilib used to mean that you would compile both 32bit and 64bit system libraries back when I used an AMD64 system long ago. Why has this changed? Don't give me that "there's no easy solution crap", it was done otherwise before and it was Better (tm) then. It used to be so that you couldn't get conflicting library versions on your system because installing eg Mesa with USE=multilib compiled both 32bit and 64bit libraries. This precompiled binary strategy sounds to me like turning multilib systems into some kind of unholy half-breed between a release-based binary distro and a rolling release source based distro. And no, stuff in Wine aren't precompiled dll's. It's Gentoo that's prebuilt here, not Wine.

nanonyme · n00b Joined: 20 Dec 2008 Posts: 5

Also to clarify the situation a bit:
Wine doesn't use precompiled dll's. Wine uses source code that is purposefully compiled as 32bit native Linux libraries so Wine could run 32bit Windows code. Get your facts straight.

loftwyr · Posted: Mon Dec 22, 2008 7:36 pm Post subject:

Gentoo has had precompiled emul libs since I started using the 2004.3 64bit version. It isn't lazyness, it's the fact that there isn't a way within the portage structure to manage two simultaneous profiles.

The emul base was the best that can be done until a way to manage the issues can be done itself.

If you'd like, you can create your own libs using a 32bit chroot and have the debug libraries attached. Most of us aren't developers so we don't need the debug aspect for the few 32bit programs we use (personally, I only have skype left).
_________________
My emerge --info
Have you run revdep-rebuild lately? It's in gentoolkit and it's worth a shot if things don't work well.
Celebrating 5 years of Gentoo-ing.

devsk · Posted: Mon Dec 22, 2008 9:15 pm Post subject:

nanonyme · n00b Joined: 20 Dec 2008 Posts: 5

Yeah, actually I *did* end up making a 32bit chroot before starting this conversation. I think that's even more of a hack (yeah, an associate of mine said he was told emul libs are a hack when he filed a bug related to a program using them) than the emul-linux-x86. One solution for the problem I mentioned in the title would be to create emul-linux-x86-foo-dbg for every single emul-linux-x86-foo package that would give the required information. Do you actually think they've done good work when they didn't realize that that's a good idea even when every other binary distro does that since it's essential for debugging stripped binaries?
Afaik you don't have to maintain headers generally and config files though in a different fashion for the two architectures. Haven't yet come across a utility that required different config files and I was under the impression that the headers are identical and just do ifdef macros to find out whether the system is 32bit or 64bit. The fact that you have to maintain two sets of libraries, on the other paw, is pretty obvious. Don't you have to do it now? Actually the current setup might get *interesting* to say at least when you get headers in your /usr/include that conflict with the libraries used for linking in /usr/lib32. I would expect that to lead into build failures at least in some cases.