
Here is an email from the DBD:pg guys describing what _GNU_SOURCE does.

---------------------------------------------------------------------------

Jeroen Ruigrok/asmodai wrote:
> It's a glibc thing.
> 
> Look at glibc's include/features.h:
> 
> _GNU_SOURCE          All of the above, plus GNU extensions.
> 
> Which means it enables all this:
> 
> __STRICT_ANSI__, _ISOC99_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE,
> _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, _LARGEFILE_SOURCE,
> _LARGEFILE64_SOURCE, _FILE_OFFSET_BITS=N, _BSD_SOURCE, _SVID_SOURCE         
> 
> -- 
> Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
> PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
> http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
> There is no greater sorrow than to recall, in misery, the time when we
> were happy...
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 28 Sep 2003 11:07:58 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
_GNU_SOURCE
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> _GNU_SOURCE          All of the above, plus GNU extensions.
>>
>> Which means it enables all this:
>> 
>> __STRICT_ANSI__, _ISOC99_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE,
>> _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED, _LARGEFILE_SOURCE,
>> _LARGEFILE64_SOURCE, _FILE_OFFSET_BITS=N, _BSD_SOURCE, _SVID_SOURCE         

Hm.  So is crypt_r() a GNU extension?  I would've thought it was
specified by some standard or other.  Perhaps the real issue here
is that /usr/include/crypt.h is using the wrong control symbol.
At least in RHL 8.0, it definitely uses __USE_GNU to hide crypt_r
and the associated struct type.

			regards, tom lane

Sun, 28 Sep 2003 11:48:04 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: _GNU_SOURCE 
-On [20030928 17:52], Tom Lane (tgl@sss.pgh.pa.us) wrote:
>Hm.  So is crypt_r() a GNU extension?  I would've thought it was
>specified by some standard or other.  Perhaps the real issue here
>is that /usr/include/crypt.h is using the wrong control symbol.
>At least in RHL 8.0, it definitely uses __USE_GNU to hide crypt_r
>and the associated struct type.

crypt() is a 4.3 BSD, SVID 3, Unix 95, Unix 98.

crypt_r() though, is a GNU extension:
http://lists.debian.org/lsb-discuss/2001/lsb-discuss-200103/msg00026.html
and from:
http://docs.mandragor.org/files/Programming_languages/C/glibc-2.2.3/libc_32.html#SEC661

"The crypt_r function is a GNU extension."

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Though this be madness, yet there is a method in it...

Sun, 28 Sep 2003 18:05:02 +0200
Jeroen Ruigrok/asmodai <asmodai@wxs.nl>
Re: _GNU_SOURCE
Jeroen Ruigrok/asmodai wrote:
> -On [20030928 17:52], Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >Hm.  So is crypt_r() a GNU extension?  I would've thought it was
> >specified by some standard or other.  Perhaps the real issue here
> >is that /usr/include/crypt.h is using the wrong control symbol.
> >At least in RHL 8.0, it definitely uses __USE_GNU to hide crypt_r
> >and the associated struct type.
> 
> crypt() is a 4.3 BSD, SVID 3, Unix 95, Unix 98.
> 
> crypt_r() though, is a GNU extension:
> http://lists.debian.org/lsb-discuss/2001/lsb-discuss-200103/msg00026.html
> and from:
> http://docs.mandragor.org/files/Programming_languages/C/glibc-2.2.3/libc_32.html#SEC661
> 
> "The crypt_r function is a GNU extension."

BSD/OS doesn't have crypt_r(), and crypt() manual page says:

     The crypt() function may not be safely called concurrently from multiple
     threads, e.g., the interfaces described by pthreads(3).

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sun, 28 Sep 2003 12:37:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: _GNU_SOURCE
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Jeroen Ruigrok/asmodai wrote:
>> "The crypt_r function is a GNU extension."

> BSD/OS doesn't have crypt_r(), and crypt() manual page says:

>      The crypt() function may not be safely called concurrently from multiple
>      threads, e.g., the interfaces described by pthreads(3).

Right.  But whether crypt is re-entrant or not isn't really the issue
here.  The problem is that the standard RHL 8 version of Perl is
installed in such a way that <perl.h> fails to compile unless crypt_r's
struct typedef is visible.  I have not looked, but I surmise this must
mean that they configured Perl with _GNU_SOURCE defined.  Maybe it was
done so Perl could get at crypt_r, but more likely it was for some other
reasons altogether ...

			regards, tom lane

Sun, 28 Sep 2003 12:53:36 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: _GNU_SOURCE 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Jeroen Ruigrok/asmodai wrote:
> >> "The crypt_r function is a GNU extension."
> 
> > BSD/OS doesn't have crypt_r(), and crypt() manual page says:
> 
> >      The crypt() function may not be safely called concurrently from multiple
> >      threads, e.g., the interfaces described by pthreads(3).
> 
> Right.  But whether crypt is re-entrant or not isn't really the issue
> here.  The problem is that the standard RHL 8 version of Perl is
> installed in such a way that <perl.h> fails to compile unless crypt_r's
> struct typedef is visible.  I have not looked, but I surmise this must
> mean that they configured Perl with _GNU_SOURCE defined.  Maybe it was
> done so Perl could get at crypt_r, but more likely it was for some other
> reasons altogether ...

Do we want to try this approach that the DBD:pg guys are using?

	http://gborg.postgresql.org/pipermail/dbdpg-general/2003-September/000452.html

It involves "$Config{q{ccflags}};".  I think they can use it because
they are using Makefile.PL, while our plperl is not, so maybe we can't
use it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 8 Oct 2003 23:40:07 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: _GNU_SOURCE
Bruce Momjian writes:

> Do we want to try this approach that the DBD:pg guys are using?
>
> 	http://gborg.postgresql.org/pipermail/dbdpg-general/2003-September/000452.html
>
> It involves "$Config{q{ccflags}};".  I think they can use it because
> they are using Makefile.PL, while our plperl is not, so maybe we can't
> use it.

There is a reason we don't use MakeMaker anymore, and it is exactly to
avoid using the Perl-provided ccflags.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 9 Oct 2003 13:06:46 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: _GNU_SOURCE
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > Do we want to try this approach that the DBD:pg guys are using?
> >
> > 	http://gborg.postgresql.org/pipermail/dbdpg-general/2003-September/000452.html
> >
> > It involves "$Config{q{ccflags}};".  I think they can use it because
> > they are using Makefile.PL, while our plperl is not, so maybe we can't
> > use it.
> 
> There is a reason we don't use MakeMaker anymore, and it is exactly to
> avoid using the Perl-provided ccflags.

OK, next question is whether we should use _GNU_SOURCE only for plperl
compile, rather than everything.  _GNU_SOURCE seems to do lots of stuff
that I am uncertain about.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 9 Oct 2003 09:41:00 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: _GNU_SOURCE
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, next question is whether we should use _GNU_SOURCE only for plperl
> compile, rather than everything.  _GNU_SOURCE seems to do lots of stuff
> that I am uncertain about.

We've been using it for awhile, and it's not broken anything.  Why are
you so eager to make build changes with potentially wide ramifications
so late in the beta cycle?  I didn't agree with your changes to CFLAGS
yesterday, either.  The risk of breaking things on some platform greatly
outweighs the potential benefits at this stage.

			regards, tom lane

Thu, 09 Oct 2003 11:00:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: _GNU_SOURCE 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, next question is whether we should use _GNU_SOURCE only for plperl
> > compile, rather than everything.  _GNU_SOURCE seems to do lots of stuff
> > that I am uncertain about.
> 
> We've been using it for awhile, and it's not broken anything.  Why are
> you so eager to make build changes with potentially wide ramifications
> so late in the beta cycle?  I didn't agree with your changes to CFLAGS

I don't know what the ramifications of _GNU_SOURCE are, but we have run
longer without it than with it.  Seems safest to have it only where we
need it, in plperl.

> yesterday, either.  The risk of breaking things on some platform greatly
> outweighs the potential benefits at this stage.

Well, the compile flags were broken by almost any measure.  I don't
want to ship without optimization for 7.4 for all those platforms.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 9 Oct 2003 11:25:42 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: _GNU_SOURCE
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> We've been using it for awhile, and it's not broken anything.  Why are
>> you so eager to make build changes with potentially wide ramifications
>> so late in the beta cycle?

> I don't know what the ramifications of _GNU_SOURCE are, but we have run
> longer without it than with it.  Seems safest to have it only where we
> need it, in plperl.

No can do --- _GNU_SOURCE affects the results of configure.  We either
use it or we don't, we don't get to be selective about it.

			regards, tom lane

Mon, 13 Oct 2003 21:01:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: _GNU_SOURCE 