Re: glibc 2.2 vs 2.3 issue back again



Roger Leigh wrote:
> Well, Linux 2.6 + a recent glibc use NPTL threads, whereas 2.4 will
> only work with LinuxThreads (google will give you all the detail).
> This shouldn't usually make a difference for an application, though,
> since the glibc ABI didn't change, AFAICT.

The bare system calls __NR_signal and __NR_sigaction are incompatible
between Linux 2.4 and Linux 2.6 on x86. Namely, return from signal
handler is different in a way that matters to some executable
compiled binary application programs. Some of my completely-
static programs (no shared libraries, no glibc, no ld-linux.so)
that run on Linux 2.4 do not run correctly on Linux 2.6.
glibc tries to mask the difference; in most cases it succeeds.

The "glibc ABI" is an interesting term. Most glibc users would say
that does not include ld-linux.so.2, whereas glibc developers say
that ld-linux.so.2 definitely is an inside part of the glibc ABI.

In any case, the "glibc ABI" does change: usually it gets bigger.
Look at the Versions defined by libc.so.6 -> libc-2.3.5, and you see:
GLIBC_2.0,
GLIBC_2.1, GLIBC_2.1.1, GLIBC_2.1.3,
GLIBC_2.2, GLIBC_2.2.1, GLIBC_2.2.2, GLIBC_2.2.3, GLIBC_2.2.4, GLIBC_2.2.6,
GLIBC_2.3, GLIBC_2.3.2, GLIBC_2.3.3, GLIBC_2.3.4,
GLIBC_PRIVATE
so there are 14 different "glibc ABI" plus GLIBC_PRIVATE.
In theory these are backward compatible (along any directed path to
the root of the Version tree; and not counting the cases such as popen()
where the semantics required by the Standard changed), but in practice
sometimes they aren't because of bugs.

--
.



Relevant Pages

  • [Full-Disclosure] THREATCON HITTING DANGEROUS LEVELS!
    ... > This is the linux glibc bootstrap code behaviour. ... and only am using linux ia32. ... i think maybe a kernel patch is the best place for this.. ...
    (Full-Disclosure)
  • Re: [9fans] impressive
    ... that they have no interest in supporting compilers other than gcc. ... The only OSes supported in the [glibc] tree are Linux and to some ... Only Linux is supported... ...
    (comp.os.plan9)
  • *ix -> linux (any cpu, any gcc, any glibc) cross compiler
    ... any cpu type) but running on your favorite non-Linux ... end up with a complete working gcc and glibc. ... support could be added without much ado. ... The idea is, now us Linux developers ...
    (comp.unix.solaris)
  • *ix -> linux (any cpu, any gcc, any glibc) cross compiler
    ... any cpu type) but running on your favorite non-Linux ... end up with a complete working gcc and glibc. ... support could be added without much ado. ... The idea is, now us Linux developers ...
    (comp.unix.bsd.freebsd.misc)
  • *ix -> linux (any cpu, any gcc, any glibc) cross compiler
    ... any cpu type) but running on your favorite ... end up with a complete working gcc and glibc. ... support could be added without much ado. ... The idea is, now us Linux developers ...
    (comp.os.linux.embedded)