[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: real LSB compliance



On Sun, 1 Jul 2001, Joey Hess wrote:

> Matt Zimmerman wrote:
>> I'd do it, but I can't seem to find a source code bundle.  There are, as you
>> probably noticed, aliened .debs in the FTP area.

> You might want to try their sourceforge cvs repository. The lack of a
> source code tarball was disconcerting, yes.

>>>    Checking symbols in /lib/libc.so.6
>>>    fgetpos64 has version GLIBC_2.2, expecting GLIBC_2.1
>>>    fgetwc has version GLIBC_2.2, expecting
>>>    fgetwc_unlocked has version GLIBC_2.2, expecting
>>>    getrlimit64 has version GLIBC_2.2, expecting GLIBC_2.1
>>>    getwc has version GLIBC_2.2, expecting
>>>    msgctl has version GLIBC_2.2, expecting GLIBC_2.0
>>>    posix_memalign has version GLIBC_2.2, expecting
>>>    shmctl has version GLIBC_2.2, expecting GLIBC_2.0
>>>    vfwscanf has version GLIBC_2.2, expecting

>> Since glibc 2.2 is backward-compatible with 2.0 and 2.1, what is the point of
>> these checks?  Looks like I have some documentation to read to find out what
>> this tool is trying to accomplish.

> Damned if I know. The spec does include symbol versions for most of the
> symbols in glibc. It doesn't seem to say why.

This is how the LSB defines the ABI that systems must support in order to be
considered compliant.  I understand that one of the principal aims of the LSB
is to make it possible to install binary packages on multiple distros,
regardless of vendor.  This requires that it be very explicit what versions of
what libraries the third-party vendor can depend on being present; in the case
of glibc, where 'libc.so.6' may contain a number of incompatible
implementations of the same function, it's also necessary to be explicit about
the symbol versions.

The fact that their compatibility testing tools identify Debian as
non-compliant because the default symbol versions in glibc2.2 don't match what
LSB is looking for underscores the need for TWO tests of LSB compatibility:
one, which appears to be what everyone here is looking for, would test whether
the system can support LSB packages being installed; the other would test
whether a system can be used for building LSB packages.  Since binaries
compiled on woody would link against GLIBC_2.2 symbols, woody might pass the
first of these tests but would fail the second (which is ok).

Steve Langasek
postmodern programmer



Reply to: