The end of the multiarch era?

Posted Jul 13, 2006 11:56 UTC (Thu) by dmantione (guest, #4640)
Parent article: The end of the multiarch era?

I couldn't disagree more with the author. Of course his reasoning is a
fallacy, but apparently the author disagrees with backwards compatibility
regardless wether RPM works correctly.

All Linux users befefit greatly because of the backward compatibility of
the kernel. You can simply upgrade your kernel without fear of breaking
your system. No such compatibility exists for many user space
applications. I'm quite sure most readers here have seen the famous glibc
missing symbol messages.

Sure, recompiling is a possibility for open source applications. I'm
quite confident few people have systems where they compiled all
applications themselves. Nor do I have the idea that people desire to
recompile all their application when they upgrade a library.

Lastly /lib64 was a very smart choice. It is mandated by the x86_64 ABI
http://www.x86-64.org/documentation/abi-0.96.pdf, so complain to the
authors about it.

/lib64 is based two ideas:
* It must be possible to install 32-bit RPMs on both i386 and x86_64
systems without change.
* Source code can be changed to use /lib64, binaries cannot. So, to allow
existing rpms to install on x86_64 systems, they should be able to find
their libraries in /lib.

This does not just benefit developers of closed source software, but also
any open source project that distributes binaries.

Try our Free Pascal i386 RPM and note that just magically works on your
Linux system, regardless which libc you use or wether you use i386 on
x86_64:
ftp://ftp.freepascal.org/pub/fpc/dist/i386-linux-2.0.2/rp...

That is how software is supposed to work.

Besides multiarch not just benefits the user who wants to use software,
but also the developer who wants to support both 32 and 64 bit. I wish
multiarch a long and healthy future.

The end of the multiarch era?

Posted Jul 13, 2006 13:09 UTC (Thu) by kleptog (subscriber, #1183) [Link] (3 responses)

All Linux users befefit greatly because of the backward compatibility of the kernel. You can simply upgrade your kernel without fear of breaking your system. No such compatibility exists for many user space applications. I'm quite sure most readers here have seen the famous glibc missing symbol messages.

Sorry? The backward compatability of glibc is leagues ahead of the kernel's. Yes, back in 2.4 you could (and I did) upgrade without care, but these days you have to remember to upgrade hotplug, sorry, udev and any of the other programs that need simultaneous upgrades.

OTOH, glibc has backward compatability going back several versions. There are multiple versions of fdopen for example, to make sure programs get exactly the version they compiled with. The kernel doesn't even try to provide that kind of compatability.

Lastly /lib64 was a very smart choice.

The biggest problem with /lib64 is that people, rather than looking at how other archtectures had been doing it for years, went off and invented their own inflexible system. They even ignored existing solutions, see /usr/lib/i[3456]86 for storing libraries optimised for specific CPUs. /lib64 is bi-arch, not multiarch. It will hopefully go the way of the dodo to make place for true multiarch.

In that I agree with you, multiarch is the way of the future. We're just not there yet.

The end of the multiarch era?

Posted Jul 13, 2006 14:09 UTC (Thu) by dmantione (guest, #4640) [Link] (2 responses)

No, we've had a lot more breakage trouble with Glibc than with the
kernel. Glibc breaks compatibility within minor versions. An example of
such breakage:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90002

It is true that glibc has backwards compatibility functionality inside,
and things seem to be improving, but for Free Pascal we have had to
stay away from it, it was simply impossible to support multiple
distributions when we had libc dependencies.

Note that on Darwin & Solaris we do use libc, and as of yet we never had
any breakage.

The end of the multiarch era?

Posted Jul 13, 2006 18:11 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

I think you're comparing apples to oranges here. You're comparing a bug in glibc (which was fixed) to the fact that the kernel breaks backward compatability permanently in "minor" releases. devfs was removed in 2.6.13. Systems using udev won't work with kernel versions older than 2.6.15. In the middle is hotplug.

Having the same userspace work for all versions of 2.6 kernels is just about impossible.

The end of the multiarch era?

Posted Jul 13, 2006 19:11 UTC (Thu) by dmantione (guest, #4640) [Link]

It was not fixed, you are confusing the _res issue with the errno issue.

The 1.0.10 compiler from 2003 still works on modern kernels, so we can
test:

daniel@laptop:~> cat test.pas
program test;

uses inet;

begin
end.

daniel@laptop:~> rpm -q -a|grep glibc
glibc-2.3.3-118
glibc-locale-2.3.3-118
glibc-devel-2.3.3-118
daniel@laptop:~> /usr/local/lib/fpc/1.0.10/ppc386 -n
-Fu/usr/local/lib/fpc/1.0.10/units/linux/* test
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x3a2): In
function `_INET$$_$$_THOST_$$_NAMELOOKUP$STRING':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x40d): In
function `_INET$$_$$_THOST_$$_ADDRESSLOOKUP$THOSTADDR':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x742): In
function `_INET$$_$$_TNET_$$_NAMELOOKUP$STRING':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0x79a): In
function `_INET$$_$$_TNET_$$_ADDRESSLOOKUP$LONGINT':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0xa6c): In
function `_INET$$_$$_TSERVICE_$$_NAMELOOKUP$STRING$STRING':
: undefined reference to `h_errno'
/usr/local/lib/fpc/1.0.10/units/linux/inet/inet.o(.text+0xb37): more
undefined references to `h_errno' follow
test.pas(7) Error: Error while linking
daniel@laptop:~>

The issue was solved in the modern compilers by coding a netdb
package in Pascal, and it never gave us trouble ever again.

I think you are right about the kernel versus its system tools. However,
for applications the kernel has remained remarkably compatible. We
recently discovered that we were still using a system call that was
replaced by a more advanced one in kernel 2.0 (we are one of the older
free software projects), it still worked.

The end of the multiarch era?

Posted Jul 13, 2006 13:57 UTC (Thu) by wookey (guest, #5501) [Link] (1 responses)

Lastly /lib64 was a very smart choice.

Sorry - that's not true. It's a very limiting choice. It assumes there is only one case where you might want more than one arch present - mixing 32 bit and 64 bit binaries of the same(ish) CPU architecture. The multi-arch concept is much more widely useful than that, as a couple of people have mentioned above, and described in some detail at http://lackof.org/taggart/hacking/multiarch/.

It can help with things like cross-building (somewhere to put target-system binaries (e.g. ARM) needed during the build process which you are going to run using an emulator such as QEMU. Mixing glibc and uclibc, mixing big-endian and little endian code, mxing OS stuff (having some windows programs installed on your linux system), etc. A properly-designed multi-arch system make all sorts of interesting things possible.

Debian is implementing a scheme which allows arbitrary mixes of architectures:

The end of the multiarch era?

Posted Jul 13, 2006 14:14 UTC (Thu) by dmantione (guest, #4640) [Link]

Sure, you can generalize that /lib64 can be improved to random
architectures. It is even a good idea. In the meantime, Debian (and
derivates) is one of the few x86_64 distribution that cannot flawlessly
run x86 binaries. In typical Debian style, it will take years to
develop.

Considering this, /lib64 was a good choice.