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.
Thread beginning with comment 393189
To view parent comment, click here.
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

RE[6]: Always On the Cards
by segedunum on Fri 6th Nov 2009 13:23 in reply to "RE[5]: Always On the Cards"
segedunum Member since:
2005-07-06

Because that's a crap hodge-podge 'solution' for the fact that Linux distributions have no way to handle the installation of third-party software. There's no standardised way for any distribution to acually handle that or know what's installed, which is extremely essential when you are dealing with third-party software. Conflicts can and do happen and the fact that anyone is having to do this is so amateurish it isn't believable.

It doesn't handle ABI versions, doesn't handle slightly different architectures like i686 that could handle the binaries..... It's such a stupid thing to suggest ISVs do it's just not funny.

It's the sort of 'solution' that makes the majority of ISVs think that packaging for Linux distributions is just like the wild west. Telling those ISVs that they are silly and wrong is also stupid and amateurish in the extreme but still people believe they are going to change things by saying it.

Edited 2009-11-06 13:39 UTC

Reply Parent Score: 2

RE[7]: Always On the Cards
by sbenitezb on Fri 6th Nov 2009 16:05 in reply to "RE[6]: Always On the Cards"
sbenitezb Member since:
2005-07-22

Because that's a crap hodge-podge 'solution' for the fact that Linux distributions have no way to handle the installation of third-party software.


Linux distributions should handle only their own packages. Everything else should go in /usr/local. There are installers (like those for Windows) that companies can use to make the install process more friendly. And just as you said ISVs are not distributing versions for Linux of their software, I remember have installed many closed source software for testing. Most of them had an install script that did the job and installed successfully in /usr/local.

There's no standardised way for any distribution to acually handle that or know what's installed,


Why does it matter? Can the package manager update the closed source software itself? No. In Windows, if you want to update an application, you have to buy a new version and reinstall. You are really thinking that ISVs aren't distributing Linux versions because the package managers don't integrate well with them? Silly.

which is extremely essential when you are dealing with third-party software. Conflicts can and do happen and the fact that anyone is having to do this is so amateurish it isn't believable.


As amateurish as in the Windows world, where most applications provide their own copy of libraries which are already available in a normal Windows installation. That doesn't stop them from delivering.
If anything, the LSB should really be enforced.

It doesn't handle ABI versions, doesn't handle slightly different architectures like i686 that could handle the binaries..... It's such a stupid thing to suggest ISVs do it's just not funny.


Oh, but you have the solution right? Because last time I checked, ISVs are not distributing Linux solutions because they are not developing them for a start. And then you have the flash plugin shit that almost recently got 64bits support for Linux. Distribution was never a problem, development was.

It's the sort of 'solution' that makes the majority of ISVs think that packaging for Linux distributions is just like the wild west. Telling those ISVs that they are silly and wrong is also stupid and amateurish in the extreme but still people believe they are going to change things by saying it.


But you seem to think that ISVs have Linux developers and have ported their software to work on Linux but they are unable to package their software and that's why they dont' deliver, right? Sweet Jesus, open your eyes. ISVs don't distribute Linux versions because they develop their software with MFC, .Net and even more rare APIs that are not available in multiple architectures, and they use 32bits specific integers, etc.

Reply Parent Score: 4

RE[7]: Always On the Cards
by tobyv on Sun 8th Nov 2009 05:36 in reply to "RE[6]: Always On the Cards"
tobyv Member since:
2008-08-25

Linux distributions have no way to handle the installation of third-party software.


Sure there is!

Install:
tar -xC /opt package_static.tar

Uninstall:
rm -r /opt/package_static

The (statically linked) future is now!

Reply Parent Score: 1

RE[6]: Always On the Cards
by MrWeeble on Fri 6th Nov 2009 14:56 in reply to "RE[5]: Always On the Cards"
MrWeeble Member since:
2007-04-18

Here is a potential maintenance problem with that script

Lets say that AMD create a new architecture in a couple of years and let's call it x86_86_2. x86_86_2 is to x86_86, what i686 is to i386, so it it perfectly capable of running legacy x86_86 code, it just runs a little better if given x86_86_2 code.

Now let's install World of Goo on this machine, it may be a few years old by this point, but it is a very cool and addictive game so we still want it.

The script checks the machine architecture. Is it "x86_64"? No. Therefore it runs using the 32 bit architecture. Sure it will work, but it should be running the 64 bit version not the 32-bit version.

Now what if it was compiled as a single set of FatElf binaries

WorldOfGoo.bin gets run, The OS "knows" that it is running x86_64_2 and looks at the index to see if there is any x86_64_2 code in the binary; there isn't, but it also "knows" that x86_64 is the second best type of code to run (followed probably by i686, i586, i486, i386). It finds the x86_64 binary and executes it. That binary looks in ./libs for the library files and for each one, performs the same little check.

Sure it will take a few milliseconds extra, but it will run the right version of code on future, unknown platforms

To my mind, FatElf is an elegant and simple solution to this sort of problem

Reply Parent Score: 2

RE[7]: Always On the Cards
by siride on Fri 6th Nov 2009 16:20 in reply to "RE[6]: Always On the Cards"
siride Member since:
2006-01-02

Better solution is just to have a better detection script. Or have a system-detection script that is part of the LSB and thus LSB-compliant distros that you can call into to determine what arch to use. This does not require changes to the kernel, glibc, ld-linux.so and the ELF format. The latter is assuredly not an elegant solution.

Honestly, though, arches aren't added that frequently and the core name of the arch can be detected easily. So until 128 comes out, we should be fine.

Reply Parent Score: 2

RE[7]: Always On the Cards
by smitty on Fri 6th Nov 2009 19:43 in reply to "RE[6]: Always On the Cards"
smitty Member since:
2005-10-13

Sure, you'd be running a slightly slower version of the code. But how often does that happen, really? There are very few architecture changes that maintain backwards compatibility like that which are worth distributing a completely new version of your code for. x64 is one, that probably won't happen again for decades. Maybe you have a 386 version with a Core2 Duo optimized version as well, but I just don't see that being used at all.

Anyway, it's easy to workaround. You just add a native app to the distro which the script would call, something like xdg-get-architecture, which would return that list for you instead of sticking that functionality within the ELF specification itself.

Reply Parent Score: 2

RE[7]: Always On the Cards
by somebody on Mon 9th Nov 2009 12:50 in reply to "RE[6]: Always On the Cards"
somebody Member since:
2005-07-07

lol, funny world this is... script is bound to be stupid and one additional if is impossible? script can't deduct anything more than basic condition with one basic response?

based on your words I seriously hope none of your scripts will ever be in linux as they would be bound to be limited and prone to be stupid.

stick to toy light sabers, luke;) real one might cut off your hand

Reply Parent Score: 2