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 393246
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Always On the Cards
by MrWeeble on Fri 6th Nov 2009 14:56 UTC 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