FOSDEM: Multiarch on Debian and Ubuntu

Posted Feb 28, 2012 16:33 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: FOSDEM: Multiarch on Debian and Ubuntu by pagerc
Parent article: FOSDEM: Multiarch on Debian and Ubuntu

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.

to post comments

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.