Re: [PATCH] #undef __GLIBC__

[Robert Millan <rmh at aybabtu dot com>]

On Tue, Nov 15, 2005 at 01:59:38PM +0000, Mike Frysinger wrote:
> On Tue, Nov 15, 2005 at 11:38:39AM +0100, Robert Millan wrote:
> > On Tue, Nov 15, 2005 at 10:56:03AM +0100, Jakub Jelinek wrote:
> > > On Tue, Nov 15, 2005 at 10:44:37AM +0100, Robert Millan wrote:
> > > > On GNU/kFreeBSD, __GLIBC__ is a pre-processor macro.  This patch fixes
> > > > features.h to #undef it before re-defining it to its proper value.
> > > > 
> > > > 2005-11-15  Robert Millan  <robertmh@gnu.org>
> > > > 
> > > >         * include/features.h: #undef __GLIBC__ before #define.
> > > 
> > > That's IMNSHO the wrong fix.  You should change GCC, so that it doesn't
> > > define __GLIBC__ as a preprocessor macro
> > 
> > We added this to GCC on purpose, because otherwise there's no way to identify
> > Glibc.
> 
> whats wrong with just letting glibc define it ?  we let features.h
> define __GLIBC__ for us in uClibc systems rather than mucking around in
> in gcc and we have yet to hit a spot where this didnt work

The problem with that is that checks may happen before features.h (or any
header) is included.

Contrary to what may seem, in practical terms, in your situation the equivalent
of the pre-processor __GLIBC__ we have on GNU/kFreeBSD is NOT the macro of the
same name defined in features.h.  It is the __linux__ macro which is often
checked [1] to indicate Glibc (or similar, like uclibc).  The reason for this
seemingly contradictory claim is that __linux__ is in pre-processor while
__GLIBC__ (on GNU/Linux) isn't.

Now you'll say that __linux__ should only be used for kernel checks (and I
agree), but we have to adhere to the facts, which are that because there's no
other way to check for Glibc using pre-processor only, lots of programs use
__linux__ instead.  When we port such programs, we usualy change them like:

  -#ifdef __linux__
  +#if defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)

  /* __GNU__ is for GNU/Hurd, which doesn't define __GLIBC__ either */

We also have __FreeBSD_kernel__.  Like __linux__, we use it for kernel checks
(i.e. those that are the same for FreeBSD [1] and for GNU/kFreeBSD).  But unlike
__linux__, we can't use it to extrapolate anything from userland, since unlike
Linux, there are two much different systems based on the same kernel.

[1] FreeBSD doesn't define __FreeBSD_kernel__ yet.  We expect they will add it
    eventualy.

P.S:  Yes, I know the right way to handle portability is using autoconf.  But I
  didn't write all these non-autoconf programs, nor do I have time (or interest)
  in migrating them.  I'm just porting them.

-- 
Robert Millan