Bruce Momjian <pgman@candle.pha.pa.us> writes:
> That _GNU_SOURCE has always bothered me. What does it control, exactly?
> It seems to control a lot.
Well, without it I get (on RHL 8.0)
gcc -O2 -g -fpic -I. -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -I../../../src/include -c -o plperl.o
plperl.c
In file included from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/op.h:480,
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/perl.h:2209,
from plperl.c:60:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/reentr.h:602: field `_crypt_struct' has incomplete type
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/reentr.h:747: confused by earlier errors, bailing out
make: *** [plperl.o] Error 1
The relevant chunk of that Perl header is
#ifdef HAS_CRYPT_R
#if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD
CRYPTD* _crypt_data;
#else
struct crypt_data _crypt_struct;
#endif
#endif /* HAS_CRYPT_R */
and the problem is that HAS_CRYPT_R has gotten defined but "struct
crypt_data" has not. It's been awhile since I looked at this, but I
think that Perl configures HAS_CRYPT_R on the basis of a link-only test
for crypt_r(), which will succeed regardless of -D symbols. And (in
this Linux version, anyway) /usr/include/crypt.h only defines struct
crypt_data if __USE_GNU is defined (which comes from _GNU_SOURCE).
So we're more or less stuck --- perl.h simply does not compile without
_GNU_SOURCE on this platform.
This is arguably a configuration bug in Perl; we have hit comparable
difficulties in PG, and had to solve them by the expedient of testing
for both compile-time and link-time presence of library features.
They're not being careful enough.
Experimenting, I notice that ecpg also currently fails to compile
without _GNU_SOURCE on that box. It looks to me like the system headers
have a rather arbitrary set of ideas on what to remove when _GNU_SOURCE
isn't defined...
regards, tom lane