FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 15:48 UTC (Tue) by pagerc (guest, #53182)
Parent article: FOSDEM: Multiarch on Debian and Ubuntu

This gets everyone excited, but fatelf [http://icculus.org/fatelf/] not so much? Can anyone elaborate on why they care about this vs fixing their compiled binaries to implicitly have everything embedded in the file and fixing the binutils/linkers to handle support in elf itself?

to post comments

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 16:21 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (14 responses)

Multiarch lets you do things like install an arm binary on an x86 system, assuming you've got binfmt-misc set up appropriately. Fatelf isn't going to work well in that scenario.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 16:25 UTC (Tue) by pagerc (guest, #53182) [Link] (13 responses)

I disagree, that's the whole point of fatelf, that your binaries are installed with support for all platforms you request. The binutils and elfutils would need updates to support injecting new architecture support to an existing binary and supporting libraries, but its very much possible.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 16:33 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (9 responses)

It means you download a binary that contains support for every architecture, and then strip and discard all the architectures that you don't want? It's also more complicated than that - imagine a binary that drops some data in /usr/lib/whatever. If that data is architecture specific, you still need to go to the effort of modifying the code and packaging so your fatelf executable gets the correct file. And once you're at the point of doing that, you might as well just finish the job and end up with multiarch.

Fatelf and Multiarch solve different problems. Fatelf lets you distribute a single binary that works on multiple architectures. Multiarch lets you install binaries from multiple architectures on a single system.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 17:43 UTC (Tue) by khim (subscriber, #9252) [Link] (8 responses)

Fatelf and Multiarch solve different problems.

Not entirely.

Fatelf lets you distribute a single binary that works on multiple architectures.

Not just distribute. Develop it, too.

Multiarch lets you install binaries from multiple architectures on a single system.

With fatelf you don't need to ever do that which kind of leads to initial question

It's also more complicated than that - imagine a binary that drops some data in /usr/lib/whatever.

That's responsibility of the applications.

In a lot of cases you can invent some architecture-specific solution. Often enough IA32 and x86-64 files can be shared (but ARM and IA32 can't), etc.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 17:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (7 responses)

Of course it's the responsibility of the applications! But if you're changing all the applications anyway, there's no reason to use fatelf rather than multiarch.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 18:29 UTC (Tue) by khim (subscriber, #9252) [Link] (6 responses)

Of course it's the responsibility of the applications! But if you're changing all the applications anyway, there's no reason to use fatelf rather than multiarch.

Sorry, but you've already named the reason: fatelf makes it easy to distribute binaries for multiple platforms. Multiarch does not solve this problem.

And as I've pointed above with fatelf it's easy to solve all the problems which multiarch is supposed to solve, too.

So... what exactly makes multiarch support so exciting? Modest space savings? In a world where $100 mobile phone includes gigabytes of storage? Meh...

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 18:34 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Distributions don't have to solve the problem of distributing single binaries that work on multiple architectures, so there's no reason to use fatelf.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 18:59 UTC (Tue) by jwakely (guest, #60262) [Link] (4 responses)

> fatelf makes it easy to distribute binaries for multiple platforms

What proportion of users want binaries for multiple platforms?

> In a world where $100 mobile phone includes gigabytes of storage? Meh...

My phone might have plenty of space (actually it's not _that_ much) but my netbook doesn't, I'm down to 300MB free space, and I still use that for real work. I'd really rather not have fatter binaries there.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 20:32 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

What proportion of users want binaries for multiple platforms?

What this has to do with anything? Users neither need nor want versions for different platforms. Developers do. There are usable (for ISVs) solution (fatelf) and half-usable one (multiarch).

As was noted Linux distributors are not interested in ISVs. Ok, no problem, this explains why multiarch is exciting and fatelf is not. What is not explained is why should I care about either.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 29, 2012 5:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

Wouldn't it be possible to support both? An ISV ships a fatelf binary and it would automatically use the relevant arch's libdir to find its libraries.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 29, 2012 8:00 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Everything is possible (it's just a software, after all), but is it feasible?

Distributions reject fatelf idea because they are not interested in ISVs support (yes, their hubris is this big) and without support "out-of-the-box" fatelf does not really makes sense: it's much simpler to put bunch of files in a single directory with appropriately named subdirectories and use some script to select proper binary.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Mar 7, 2012 0:18 UTC (Wed) by fest3er (guest, #60379) [Link]

... it's much simpler to put bunch of files in a single directory with appropriately named subdirectories and use some script to select proper binary.

I did this many years ago. Built binaries for SunOS (68k and SPARC), Solaris (SPARC), SysV68 (68k), SysV88 (88k), HPUX (PA-RISC) and Irix (MIPS). Put them in suitably-named subdirs and wrote a shell script that worked on all of them (though HPUX was problematic) that discovered the architecture and exec'ed the correct binary. NFS-mounted the dir everywhere; people then had the same programs at the same path regardless of which system they were using.

True multi-arch binary data files can be a pain to lay out. Especially when structs are involved. It's hard, but it can be done. We had a DB program on 68k. Worked great. But on 88k it didn't work. Many assumptions were made about where members were put and how things were aligned. We ended up using 'fillers' to force alignment. After that, the data files were usable on 68k and 88k, both big-endian. But I would expect that hton*() and ntoh*() would solve most of the endianness problems.

But, first things first. Get the library locations standardized. The rest will probably pert near fall into place.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Mar 1, 2012 12:11 UTC (Thu) by elanthis (guest, #6227) [Link] (2 responses)

That significantly complicates -- and to a degree undermines -- the ability for packages to utilize signing of installed components for verification of a system.

The files created by a package should not be modified for any reason. I should be able to do a package verification and check the checksums of the installed components.

It would be possible to update the package database with modified checksums of binaries that are "patched" by a fatelf system, but then that reduces the overall safety. Then I would only be able to check a potentially compromised system's filesystem using data that only exists in the potentially compromised system's filesystem. Without modifying binaries, I can grab the upstream original verified out-of-band package and compare its checksums directly to those on the system's filesystem image.

Yes, I realize that prelink already screws up most of this. I'm not sure if prelink is still commonly used (faster linkers like gold and strict symbol visibility control can reduce the need for prelinking, and address space randomization should be part of the dynamic loader, but maybe Linux distros haven't caught up yet).

FOSDEM: Multiarch on Debian and Ubuntu

Posted Mar 1, 2012 16:02 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

prelink only screws this up if your checksummer doesn't know about prelink's --verify, --md5 or --sha options.

FOSDEM: Multiarch on Debian and Ubuntu

Posted Mar 3, 2012 10:02 UTC (Sat) by TRS-80 (guest, #1804) [Link]

Unrelated, but I wanted to draw your attention to http://lwn.net/Articles/485008/ as I presume your email reply notification window has expired.