Glibc 2.1.1 notes....
Below is part of a reply from Joel Klecker that I got about the big
changes in glibc 2.1.x. This should help all of us determine if/why a
package needs to be recompiled. It should also give everyone interested a
bit of insight as to what we've had to contend with and why it took a bit
longer than expected :-)
----- Forwarded message -----
Basically the issue with glibc 2.1 and other libraries is
incompatible changes in libio, symbol versioning is unable to help
with this because it is the structure of FILE that changed.
In libstdc++'s case, its ABI changed due to the LFS (Large File
Summit) support in glibc 2.1 (though the libio issue would bite it as
well, if there weren't the LFS issue).
In the case of the libraries affected by the libio change, things
only break when trying to link new programs against an old library,
i.e. the resulting executable segfaults immediately at startup.
A source compatibility issue that the glibc FAQ doesn't touch on is
programs that detect utmpx.h and assume it is the same as the one in
Solaris, though I have looked at what UNIX98 specifies
(http://www.opengroup.org/onlinepubs/7908799/xsh/utmpx.h.html) for
utmpx.h and glibc conforms with that.
Here are a few FAQ entries of interest (note that the sparc and
powerpc ports have addressed most of the source compatibility issues,
though in a lot of cases, the fixes have not been applied by the
maintainer yet):
2.27. What needs to be recompiled when upgrading from glibc 2.0 to glibc
2.1?
{AJ,CG} If you just upgrade the glibc from 2.0.x (x <= 7) to 2.1, binaries
that have been linked against glibc 2.0 will continue to work.
If you compile your own binaries against glibc 2.1, you also need to
recompile some other libraries. The problem is that libio had to be
changed and therefore libraries that are based or depend on the libio
of glibc, e.g. ncurses or slang, need to be recompiled. If you
experience strange segmentation faults in your programs linked against
glibc 2.1, you might need to recompile your libraries.
Another problem is that older binaries that were linked statically against
glibc 2.0 will reference the older nss modules (libnss_files.so.1 instead of
libnss_files.so.2), so don't remove them. Also, the old glibc-2.0 compiled
static libraries (libfoo.a) which happen to depend on the older libio
behavior will be broken by the glibc 2.1 upgrade. We plan to produce a
compatibility library that people will be able to link in if they want
to compile a static library generated against glibc 2.0 into a program
on a glibc 2.1 system. You just add -lcompat and you should be fine.
The glibc-compat add-on will provide the libcompat.a library, the older
nss modules, and a few other files. Together, they should make it
possible to do development with old static libraries on a glibc 2.1
system. This add-on is still in development. You can get it from
ftp://alpha.gnu.org/gnu/glibc-compat-2.1.tar.gz
but please keep in mind that it is experimental.
3.8. I've got errors compiling code that uses certain string
functions. Why?
{AJ} glibc 2.1 has special string functions that are faster than the normal
library functions. Some of the functions are additionally implemented as
inline functions and others as macros. This might lead to problems with
existing codes but it is explicitly allowed by ISO C.
The optimized string functions are only used when compiling with
optimizations (-O1 or higher). The behavior can be changed with two feature
macros:
* __NO_STRING_INLINES: Don't do any string optimizations.
* __USE_STRING_INLINES: Use assembly language inline functions (might
increase code size dramatically).
Since some of these string functions are now additionally defined as macros,
code like "char *strncpy();" doesn't work anymore (and is unnecessary, since
<string.h> has the necessary declarations). Either change your code or
define __NO_STRING_INLINES.
{UD} Another problem in this area is that gcc still has problems on machines
with very few registers (e.g., ix86). The inline assembler code can require
almost all the registers and the register allocator cannot always handle
this situation.
One can disable the string optimizations selectively. Instead of writing
cp = strcpy (foo, "lkj");
one can write
cp = (strcpy) (foo, "lkj");
This disables the optimization for that specific call.
3.9. I get compiler messages "Initializer element not constant" with
stdin/stdout/stderr. Why?
{RM,AJ} Constructs like:
static FILE *InPtr = stdin;
lead to this message. This is correct behaviour with glibc since stdin is
not a constant expression. Please note that a strict reading of ISO C does
not allow above constructs.
One of the advantages of this is that you can assign to stdin, stdout, and
stderr just like any other global variable (e.g. `stdout = my_stream;'),
which can be very useful with custom streams that you can write with libio
(but beware this is not necessarily portable). The reason to implement it
this way were versioning problems with the size of the FILE structure.
To fix those programs you've got to initialize the variable at run time.
This can be done, e.g. in main, like:
static FILE *InPtr;
int main(void)
{
InPtr = stdin;
}
or by constructors (beware this is gcc specific):
static FILE *InPtr;
static void inPtr_construct (void) __attribute__((constructor));
static void inPtr_construct (void) { InPtr = stdin; }
3.12. I can't access some functions anymore. nm shows that they do
exist but linking fails nevertheless.
{AJ} With the introduction of versioning in glibc 2.1 it is possible to
export only those identifiers (functions, variables) that are really needed
by application programs and by other parts of glibc. This way a lot of
internal interfaces are now hidden. nm will still show those identifiers
but marking them as internal. ISO C states that identifiers beginning with
an underscore are internal to the libc. An application program normally
shouldn't use those internal interfaces (there are exceptions,
e.g. __ivaliduser). If a program uses these interfaces, it's broken. These
internal interfaces might change between glibc releases or dropped
completely.
3.15. The sys/sem.h file lacks the definition of `union semun'.
{UD} Nope. This union has to be provided by the user program. Former glibc
versions defined this but it was an error since it does not make much sense
when thinking about it. The standards describing the System V IPC functions
define it this way and therefore programs must be adopted.
Reply to: