blogtest/ posts/ FatELF

I have to say, I really liked the idea of FatELF. I'm not terribly surprised at the... er... push-back. We've seen this a lot of times in the past. A number of years ago SGI proposed some patches to use a "spare" 32-bits in a per-thread data structure to hold the GL context pointer. The patches were rejected, and the submitters were flamed. Fast forward a few years (and by I a few I mean 5-ish) we have TLS to store this sort of data in a generic way.

What's the point?

Well, some times someone has the right idea to solve a particular problem. It might not be everyone's problem, and it might not be something we (the "royal" we, of course) want to maintain moving forward. However, it might be something useful and there might be a way to generalize it to make it really useful.

How so?

The first idea that idea had about FatELF was to put multiple versions of a code compiled with optimizations for different targets in the same binary. So, put the -march=i686 and -march=core2 code in the same binary. Yeah, GCC has some features that work sort of like this. Last I tried them, it was a pain in the ass and carried some annoying "caveats".

I would also love a solution to the mixed 32-bit / 64-bit distros. Anyone that thinks /lib and /lib64 (or /lib32 of you're Ubuntu) is a good solution needs a kick in the teeth. Seriously. FatELF isn't a solution "out of the box" for that problem (how do you install a 32-bit library into an existing 64-bit library install) yet, but it doesn't seem like an insurmountable problem.

comment 1
Actually, the simplest solution would be to dump 32 bits alltogether. The minor fraction of proprietary, 32-bit software that runs on free systems can be ported to 64 bits easily. It is only proprietary systems like Mac OS or Windows that have their hands tied and have to maintain backwards compatibility, which leads to hacks like universal binaries.
Comment by anon — Wed 04 Nov 2009 06:08:55 AM PST
Ideals vs. Reality
The point of system software is to be used, not to be maintained against some conceptual ideal. In the case of backwards compatibility MacOSX and Windows have it right. They have sacrificed conceptual purity to maintain a higher level of usability. Users are maintain a relative level of satisfaction with the system and frankly I don't know of anyone who would complain at the existence of Universal binaries or 32 bit compatibility mode. I see no real drawbacks to Universal binaries. If you're someone who actually cares so much that they want N binary versions to choose from rather than 1 binary option then you're probably also someone who's capable of downloading the source and building it yourself. Is this a philosophical problem of the Linux community at large that usability is somehow secondary to "purity"?
Comment by Greg — Wed 04 Nov 2009 06:28:48 AM PST
RE: Ideals vs. Reality

The difference on Linux is that most software is distributed as source code. If someone wants to use, say, Mosaic as their browser, they just recompile it for their current CPU.

At the same time, there are a lot of use cases where having combined 32-bit / 64-bit is useful:

  • I'm a software developer, and I want to test both the 32-bit and 64-bit build of my software.
  • I'm a user, and I want to use some piece of closed-source software.
  • I'm a system administrator, and I want to have one NFS share for both 32-bit and 64-bit systems.
  • I'm a system administrator, and I want to have one rescue CD / USB key for both 32-bit and 64-bit systems.
Comment by IanRomanick — Wed 04 Nov 2009 11:23:56 AM PST
comment 4

The difference on Linux is that most software is distributed as source code.

Well, no. Most software is available as source code, which is how upstream distribute it. But as a practical matter, most software on Linux is distributed as binary packages by Fedora, Ubuntu, and others. Building from source is a somewhat theoretical ability that many people have no interest in doing (and I say that as a LinuxFromScratch user)...

Comment by Anonymous — Wed 04 Nov 2009 01:07:42 PM PST
RE: comment 4
Fair enough. I suppose I should have said "also distributed" as source. It's still a pretty significant difference from OS X and Windows. On those platforms the choice is to either have backwards compatibility or throw away existing programs. On Linux a third choice, recompiling, exists. You are completely correct that it's a non-starter for a lot of people.
Comment by IanRomanick — Wed 04 Nov 2009 01:25:48 PM PST
/lib32 and /lib64 ftl

The multilib/bi-arch in Linux is indeed a bad reinvention of the wheel. Solaris has had proper multiarch support for years. Architecture specific files would reside in /usr/lib/${ARCH}

Comment by Anonymous — Thu 05 Nov 2009 06:46:34 PM PST
Add a comment