LWN.net Logo

The end of the multiarch era?

The end of the multiarch era?

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

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.


(Log in to post comments)

The end of the multiarch era?

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

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.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds