Thread: _GNU_SOURCE
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, Pennsylvania19073
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 bypthreads(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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073 ---------------------------(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, Pennsylvania19073
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, Pennsylvania19073
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