(please CC me on replies, since I'm not subscribed to -bsd@.)

years ago, when Robert Millan improved the support for k*bsd* in gcc, he 
added the __GLIBC__ define as part of the ones provided by gcc itself 
(see [1][2]).
Unfortunately, __GLIBC__ is one of the defines provided by glibc itself 
(in the internal <features.h> included in any public header), and 
because of this (e)glibc on debian/kfreebsd has to carry the patch 
local-undef-glibc.diff. Indeed, compiling trying to compile the simple:
  #ifdef __GLIBC__
  # error __GLIBC__ defined with no includes!
  int main() { return 0; }
fails on kFreeBSD while it succeeds on Linux and Hurd.
This also causes that porting code like:
-#if defined(__linux__)
+#if defined(__linux__) || defined(__GLIBC__)
makes it work on kFreeBSD but still failing on Hurd (in situation where 
there is no #include of stdlib headers prior to that), and in the past 
I've been personally hit by this few times (and I'm not the only Hurd 
porter to have hit such situation).

Since IMHO it is awkward for a compiler to claim to be a libc, my 
suggestion (as also shown in the topic) is to drop the definition of 
__GLIBC__ done in the k*bsd* configuration of gcc.
My proposal would be to remove it upstream and, once Whezy is released, 
backport the patch for any gcc version in Debian. This should leave 
plenty of time (at least 1-1½ years) to fix the (few?) kFreeBSD-specific 
build failures and issues that could arise because of that (note that 
some of the cases were fixed in the past with Hurd porting).

What do you think? Does it sound reasonable enough?

[1] http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00050.html
[2] http://gcc.gnu.org/viewcvs?view=revision&revision=83577

Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to