>From [EMAIL PROTECTED] Fri Apr 7 13:44:59 2000
>On Wed, Apr 05, 2000 at 09:26:42AM +0200, Joerg Schilling wrote:
>> BTW: libc.so.6 is still not usable for applications that ship
>> in binary form: RedHat and SuSE use binary incompatible libraries
>> both called libc.so.6
>>
>> There is a high demand to force ReaHat and SuSE to talk together
>> and fix this. As libc.so.6 is burned out for this reason, there
>> should be a libc.so.7 that may be used again for binary distributions.
>Joerg,
>In glibc binary compatibility is not defined by the soname (which is
>libc.so.6 no matter how the actual file is named), but by the internal
>symbol versions. In theory a given symbol like fopen@GLIBC_2_1_2 is supposed
>to be compatible between Caldera/SuSE/RedHat/Debian/... libc 2.1.x. There is
>no explicit testing of this though, it would be rather hard to do too
>because the differences can be subtly and maybe often break only some apps.
>Changing symbol versions for every small bugfix would be silly too and
>quickly cause a big mess.
>Often incompatibilities are caused by other things too, like gcc libgcc1/2
>binary problems etc.
>As you can see, a glibc _up_grade should never break binaries. A downgrade of
>course can always cause problems ...
>If you compile your binaries / shlibs with glibc-2.1.2, it should work on
>all distros using 2.1.2 or later. If not, it's a bug either in glibc or your
>code. Don't hesitate to report it to the glibc folks and discuss it.
This may be your hope....
.... reality is different.
Compile cdrecord on SuSE and run it on RedHat or vice versa
and it will not work correctly because there are different bit values
used in <ctype.h>
This will cause the character classifyer in my getargs() parsing routine
to fail. The imortant part is the parsing of xxx= type options.
The bug in ReadHat or SuSE libc causes cdrecord to believe that dev=5,0
is not a device option but rather a file name if run on the wrong system.
As you see, it is not sufficient to just believe that it should
work. You need to have some sort of ABI regression test that
checks for all possible aspects of the library interface.
AT&T wrote such tests for SYSv and I believe that this is one of the
main reasons why SYSv won the the run on the commercial UNIX market.
There is also a need for the maintainer of the libraries to _understand_
what binary compatibility means and if a bug fix will be only a bug fix
or rather an incompatible change to existing interfaces.
If the maintainter of the libraries is not experienced enough for doing
this job by heart, it also helps to have a 100% regression test for
the ABI.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
