| |||||||||||||
SELF: Anatomy of an (alleged) failureSELF: Anatomy of an (alleged) failurePosted Jun 24, 2010 10:43 UTC (Thu) by michich (subscriber, #17902)In reply to: SELF: Anatomy of an (alleged) failure by cortana Parent article: SELF: Anatomy of an (alleged) failure But what you describe already works today and FatELF is not needed for it. It's called multilib.
(Log in to post comments)
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 11:00 UTC (Thu) by cortana (subscriber, #24596) [Link]
But it doesn't work today, at least on any Debian-derived distribution. You have to rely on the ia32-libs conglomeration package to have picked up the right version of a library that you want, when it was last updated, which is not a regular occurrence (bugs asking that libraries for Flash 10 are still open 2 years later).
Even if Debian did have an automatic setup for compiling all library packages with both architectures, you are then screwed because they put the amd64 libraries in /lib (with a symlink at /lib64) and the i386 libraries in /lib32. So your proprietary i386 software that tries to dlopen files in /lib fails because they are of the wrong architecture.
You could argue that these are Debian-specific problems. You might be right. But they are roadblocks to greater adoption of Linux on the desktop, and now that the FatELF way out is gone, we're back to the previous situation: waiting for the 'multiarch' fix (think FatELF but with all libraries in /lib/$(arch-triplet)/libfoo.so rather than the code for several architectures in a FatELF-style, single /lib/libfoo.so), which has failed to materialise in the 6 years since I first saw it mentioned. And which still won't fix proprietary software that expects to find its own architecture's files at /lib.
SELF: Anatomy of an (alleged) failure Posted Jun 24, 2010 17:44 UTC (Thu) by vonbrand (subscriber, #4458) [Link] That multilib doesn't work on Debian is squarely Debian's fault (my Fedora here is still not completely 32-bit free, but getting there). No need to burden the kernel for that.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 12:31 UTC (Sun) by nix (subscriber, #2304) [Link] Even if Debian did have an automatic setup for compiling all library packages with both architectures, you are then screwed because they put the amd64 libraries in /lib (with a symlink at /lib64) and the i386 libraries in /lib32. So your proprietary i386 software that tries to dlopen files in /lib fails because they are of the wrong architecture.I've run LFS systems with the /lib / /lib32 layout for many years (because I consider /lib64 inelegant on a principally 64-bit system). You know how many things I've had to fix because they had lib hardwired into them? *Three*. And two of those were -config scripts (which says how old they are right then and there, modern stuff would use pkg-config). Not one was a dlopen(): they all seem to be using $libdir as they should. This simply is not a significant problem.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 13:14 UTC (Sun) by cortana (subscriber, #24596) [Link]
I'm very happy that you did not run into this problem, but I have. IIRC it was with Google Earth. strace clearly showed it trying to dlopen some DRI-related library, followed by it complaining about 'wrong ELF class' and quitting.
SELF: Anatomy of an (alleged) failure Posted Jun 27, 2010 17:48 UTC (Sun) by nix (subscriber, #2304) [Link]
Well, DRI is a whole different kettle of worms. I suspect a problem with your OpenGL implemementation, unless Google Earth has a statically linked one (ew).
(Words cannot express how much I don't care about statically linked apps.)
SELF: Anatomy of an (alleged) failure Posted Jul 10, 2010 12:31 UTC (Sat) by makomk (guest, #51493) [Link]
Yeah, dlopen() problems with not finding libraries in /lib32 don't tend to happen, mostly because it's just easier to do it the right way from the start and let dlopen() search the appropriate directories. (Even on pure 32-bit systems, some libraries are in /lib on some systems, /usr/lib on others, and perhaps even in /usr/local/lib or $HOME/lib if they've been manually installed.)
SELF: Anatomy of an (alleged) failure Posted Jul 10, 2010 20:24 UTC (Sat) by nix (subscriber, #2304) [Link]
dlopen() doesn't search directories for you, does it? Programs generally want to look in a subdirectory of the libdir, anyway. Nonetheless they almost all look in the right place.
|
|||||||||||||