_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

-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...

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

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

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

The $Config-stuff is useable from the regular perl binary,
'perl -V:ccflags' for example.

-- Magnus

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian

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

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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

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

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

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

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