From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: Running a dynamically-linked binary built against glibc 2.2.94 (or something higher than 2.2.90) in RH 8.0 seems to be unrunnable on (null) or 7.3 (and probably lower). The problem seems to be a change in ctype. In 2.2.90, ctype.h has: extern __const unsigned short int *__ctype_b; /* Characteristics. */ ... #define __isctype(c, type) \ (__ctype_b[(int) (c)] & (unsigned short int) type) In 2.2.94 (and possibly earlier), this became: extern __const unsigned short int **__ctype_b_loc (void) __attribute__ ((__const)); ... #define __isctype(c, type) \ ((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type) Trying to run an app built on 8.0 that uses ctype results in: ./mozilla-bin: relocation error: /home/vladimir/mozilla/libmozjs.so: symbol __ctype_b_loc, version GLIBC_2.3 not defined in file libc.so.6 with link time reference This would happen with both gcc3 and gcc296 built binaries (the mozilla above was built with gcc296).
If foo.c is created as such: #include <ctype.h> __const unsigned short int **__ctype_b_loc (void) { return &__ctype_b; } __const __int32_t **__ctype_tolower_loc (void) { return &__ctype_tolower; } __const __int32_t **__ctype_toupper_loc (void) { return &__ctype_toupper; } and compiled with "gcc -shared -o foo.so foo.c", and then used as a LD_PRELOAD for the binary in question, it runs fine under (null) and presumably under 7.3 as well.
And the problem is? glibc has always been just backwards compatible, not forward compatible.