FOSDEM: Multiarch on Debian and Ubuntu

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

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.

to post comments

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.