The end of the multiarch era?

Posted Jul 13, 2006 13:09 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: The end of the multiarch era? by dmantione
Parent article: The end of the multiarch era?

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.