uClibc / glibc version conflict

Kevin Day drealin01 at cox.net
Sat Jan 7 04:30:15 PST 2006

Okay, somehow this "error" did not appear ever from numerous builds,
until I started cross-compiling everything to i686. (instead of
compiling it just for my pentium4)

While compiling GCC 3.4.5, an error occured to the toolchain, the file
ctype_noninline.h was checking for glibc version with (__GLIBC__ > 2
||  __GLIBC_MINOR__ > 2) to support two different versions of
tupper/tolower typecasts.  The error occurs when the typecast supported
is in fact the one that GCC claims glibc >= 2.3 supports.  At first
glance, I was just going to modify that line, but looking further, I
saw similar declarations all over the place.  Using a grep
to /usr/include, I found that a number of the newer functions that are
available, are being disabled by the __GLIBC_MINOR__ checks in
different programs, including Xorg.

After some quick research, I found the following:

Though, I have not touched xlocale in anyway (it may be enabled by

So, is it better to do this change or change every single line in gcc
that is effect?

Is there any chance of having some sort of option being passed such
that something like the following could be used:

 #if !defined __FORCE_NOGLIBC && (!defined _LIBC || defined
 #ifndef __USE_NEWER_GLIBC__
 #   define __GNU_LIBRARY__ 6
 #   define __GLIBC__       2
 #   define __GLIBC_MINOR__ 3
 #   define __GNU_LIBRARY__ 6
 #   define __GLIBC__       2
 #   define __GLIBC_MINOR__ 2
 #endif /* __USE_NEWER_GLIBC__

so that individual programs can be quickly hacked to use the newer or
older version and prevent other programs needing the older from getting
messed up?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uClibc-0.9.28-glibc_compat-1.patch
Type: application/octet-stream
Size: 1465 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20060107/4c686d04/attachment.obj>

More information about the hlfs-dev mailing list