Re: [HACKERS] _GNU_SOURCE

2003-10-13 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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, bu

Re: [HACKERS] _GNU_SOURCE

2003-10-09 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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

Re: [HACKERS] _GNU_SOURCE

2003-10-09 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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 ea

Re: [HACKERS] _GNU_SOURCE

2003-10-09 Thread Bruce Momjian
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

Re: [HACKERS] _GNU_SOURCE

2003-10-09 Thread Peter Eisentraut
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 i

Re: [HACKERS] _GNU_SOURCE

2003-10-09 Thread Magnus Enbom
The $Config-stuff is useable from the regular perl binary, 'perl -V:ccflags' for example. -- Magnus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Do we want to try this approach that the DBD:pg guys are using? http://gborg.po

Re: [HACKERS] _GNU_SOURCE

2003-10-08 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 > >

[HACKERS] _GNU_SOURCE

2003-09-28 Thread Bruce Momjian
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 ex

Re: [HACKERS] _GNU_SOURCE

2003-09-28 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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 interfac

Re: [HACKERS] _GNU_SOURCE

2003-09-28 Thread Bruce Momjian
Jeroen Ruigrok/asmodai wrote: > -On [20030928 17:52], Tom Lane ([EMAIL PROTECTED]) 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

Re: [HACKERS] _GNU_SOURCE

2003-09-28 Thread Jeroen Ruigrok/asmodai
-On [20030928 17:52], Tom Lane ([EMAIL PROTECTED]) 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 __

Re: [HACKERS] _GNU_SOURCE

2003-09-28 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> 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