fix for 30094 breaks HURD compilation again

[Riccardo Mottola]

Hi,

Yavor's patch is in theory correct, but in practice wrong. GLIBC is a 
mess to work with. I already tried to make the original code which used 
__USE_UNIX98 more portable.

---

Trivial patch attached.

GNU libc supports several kernels: Linux, GNU Mach+Hurd, kFreeBSD and 
(unofficially) kOpenSolaris. So the correct check in this case is for 
the symbol /_GLIBC_/, which is guaranteed to be defined on all 
glibc-based platforms.
Perhaps it's worth to leave /_linux_/ for the rare cases when another 
libc is used with Linux (uClibc, dietlibc, etc.), although I'm not sure 
if the GNUstep stack works on those systems at all.

---

It is not trivial at all! It took me one evening of testing with David 
to get that combination of defines to work on all systems I tested.
Unfortunately I don't have all the tests at hand I did, however, 
rereading from my commits, the concept is to define _XOPEN_SOURCE only 
on certain systems. Namely Linux and Hurd. My define __hurd__ was wrong 
and replaced with __GNU__

now using __GLIBC__ causes troubles on Hurd with GCC (and possibly other 
platforms which I don't remember),

I recall that the goal is not to check for GLIBC, but for certain 
platforms which need some tweaks to get broken glibc working. Sorry if 
this is not very scientific.

reading:

http://glibc-bsd.alioth.debian.org/porting/PORTING

I propose to check for linux, GNU and GLIBC. I commit the patch, let me 
know if it works for you all on different systems, I reopened the bug to 
keep track of that.

Else I think I will revert the check to my version, which was very proven.


Riccardo