Tom Lane wrote:
> 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...
I know the Pg:DBD guys had to define _GNU_SOURCE to get something
working, but it wasn't per-platform, and I was concerned about that.
They found another way to do it and have to test to see if it is going
to work for all configuration.
I just don't know if _GNU_SOURCE opens up other problems that we will
only find later --- it seems like a large knob, but if it is required,
it is required, I guess.
--
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