Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Linux As we all know, Mac OS X has support for what is called 'fat binaries'. These are binaries that can carry code for for instance multiple architectures - in the case of the Mac, PowerPC and x86. Ryan Gordon was working on an implementation of fat binaries for Linux - but due to the conduct of the Linux maintainers, Gordon has halted the effort.
Permalink for comment 393189
To read all comments associated with this story, please click here.
RE[5]: Always On the Cards
by smitty on Fri 6th Nov 2009 08:07 UTC in reply to "RE[4]: Always On the Cards"
smitty
Member since:
2005-10-13

If 3rd parties don't know how to make a good cross-distro package, it's either their own fault or a limitation of Linux that FatELF would not solve.

A good post from another site:

There seem to be two main reasons to have fatElf as advocated by its proponents:
1. distributing binaries for different architectures bundled together
2. distributing an executable and the libraries it depends on in a single package.

Both of these can be achieved today by simply putting all the binaries and all the libraries to one directory tree plus a simple script to choose the right version.

I hear cries about how difficult it is to deploy on linux because of all the distro incompatibilities. Well, lets take a look at a concrete example, such as WorldOfGoo.
It is distributed as a deb, rpm and a tar.gz. This is the relevant content of the tar.gz:

d icons
d libs32 \_ contains libogg, libvorbis, libSDL
d libs64 /
d res - game data
f readme.html
f WorldOfGoo
f WorldOfGoo.bin32
f WorldOfGoo.bin64

The WorldOfGoo shell script basically only does:

Code:

MACHINE=`uname -m`
if [ "$MACHINE" = x86_64 ]
then
LIBS=./libs64
BIN=./WorldOfGoo.bin64
else
LIBS=./libs32
BIN=./WorldOfGoo.bin32
fi

export LD_LIBRARY_PATH=$LIBS:"$LD_LIBRARY_PATH"
$BIN $@

The rpm and deb differs from the tarball only in that they put the above in /opt/WorldOfGoo and install some shortcuts and icons.

You cant say it takes a lot of effort to 'maintain' that?

Sure a shell script, however simple and posix-compatible it tries to be, is somewhat error-prone (its easy to use some non-standard-compliant features and make assumptions). Thats why I would rather see a project that factors out the operations usually done in such scripts (other common operation ive seen is locating certain directories) and provides them in a standardized way (some kind of an extended symlink framework maybe). This certainly doesn't look like a kernel problem at all.

Somebody asked why isnt it done? Maybe because status quo works as good as it does!


Edited 2009-11-06 08:11 UTC

Reply Parent Score: 6