As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8. I
get the following compile error:

gcc -O2 -g -fpic -I. -I/usr/lib/perl/5.8.0/CORE -I../../../src/include   -c -o plperl.o plperl.c -MMD
In file included from /usr/lib/perl/5.8.0/CORE/op.h:480,
                 from /usr/lib/perl/5.8.0/CORE/perl.h:2209,
                 from plperl.c:61:
/usr/lib/perl/5.8.0/CORE/reentr.h:602: field `_crypt_struct' has incomplete type
/usr/lib/perl/5.8.0/CORE/reentr.h:747: confused by earlier errors, bailing out
make[3]: *** [plperl.o] Error 1

This is running GCC 3.2 and Perl 5.8.0 on Debian unstable.

There's a thread about a similar topic on p5p:

        http://archive.develooper.com/perl5-porters@perl.org/msg75480.html

The thread suggests a trivial fix: adding -D_GNU_SOURCE to the CFLAGS
for the affected files. I checked, and this gets PL/Perl to compile
correctly. That doesn't seem like the right fix, though. Does anyone
have any comments on how to fix this properly?

Regardless of the solution we choose, I think this needs to be fixed
before 7.3 is released.

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


16 Oct 2002 22:40:49 -0400
Neil Conway <neilc@samurai.com>
PL/Perl and Perl 5.8
Neil Conway <neilc@samurai.com> writes:
> As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8.

Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3.

> There's a thread about a similar topic on p5p:
>         http://archive.develooper.com/perl5-porters@perl.org/msg75480.html

This thread makes it sound like it's Perl's problem not ours ...

> The thread suggests a trivial fix: adding -D_GNU_SOURCE to the CFLAGS
> for the affected files. I checked, and this gets PL/Perl to compile
> correctly. That doesn't seem like the right fix, though.

In view of opposing comments like
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-03/msg01452.html
I think we should stay out of this.  It is not our business to get
random Perl code to compile on random OS installations, and certainly
not our business to interject random symbol definitions that might well
break whatever solution the Perl guys themselves decide on.

			regards, tom lane

Thu, 17 Oct 2002 00:05:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PL/Perl and Perl 5.8 
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Neil Conway <neilc@samurai.com> writes:
> > As of current CVS, PL/Perl doesn't seem to compile against Perl 5.8.
> 
> Builds fine on HPUX 10.20 with Perl 5.8.0 and gcc 2.95.3.

It may also depend on the way Perl is configured. I've attached the
output of 'perl -V' on my system (using Debian's default Perl
packages).

> > The thread suggests a trivial fix: adding -D_GNU_SOURCE to the CFLAGS
> > for the affected files. I checked, and this gets PL/Perl to compile
> > correctly. That doesn't seem like the right fix, though.
> 
> In view of opposing comments like
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-03/msg01452.html
> I think we should stay out of this.

Well, I'd read that thread as saying that "Apache breaks when compiled
with -D_GNU_SOURCE", not claiming that there is something inherently
wrong with defining _GNU_SOURCE as a fix for the Perl problem.

> It is not our business to get random Perl code to compile on random
> OS installations, and certainly not our business to interject random
> symbol definitions that might well break whatever solution the Perl
> guys themselves decide on.

Well, I'm not happy with defining _GNU_SOURCE, but I don't agree that
just saying "it's a Perl problem" is a good answer. That may well be
the case, but it doesn't change the fact that a lot of people are
running 5.8.0, and will probably continue to do so during the 7.3
lifecycle[1]. We work around braindamage on other systems -- strictely
speaking, we could say "the snprintf() bug with 64-bit Solaris is a
Sun libc problem", for example.

Perhaps we can include a test for this in configure? (i.e. if
--with-perl is specified, try compiling a simple XS file that exhibits
the problem; if it fails, try it with -D_GNU_SOURCE).

Cheers,

Neil

[1] Note that I'm assuming that PL/Perl is broken with 5.8.0 on
systems other than mine, and another person's on IRC who reported the
problem to begin with. Can other people confirm the problem?

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.19, archname=i386-linux-thread-multi
    uname='linux cyberhq 2.4.19 #1 smp sun aug 4 11:30:45 pdt 2002 i686 unknown                                                                                                                                                  unknown gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-f                                                                                                                                                 PIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.0 -Darchli                                                                                                                                                 b=/usr/lib/perl/5.8.0 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendora                                                                                                                                                 rch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.0                                                                                                                                                  -Dsitearch=/usr/local/lib/perl/5.8.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/u          
                                                                                                                                        sr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -U                                                                                                                                                 afs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.0 -Dd_dosuid                                                                                                                                                  -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=de                                                                                                                                                 fine
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing                                                                                                                                                  -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O3',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -I/usr/lo                                                                                                                                                 cal/include'
    ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers                                                                                                                                                 =''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize                                                                                                                                                 =8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so.5.8.0
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_                                                                                                                                                 CONTEXT
  Built under linux
  Compiled at Sep 14 2002 17:36:21
  @INC:
    /etc/perl
    /usr/local/lib/perl/5.8.0
    /usr/local/share/perl/5.8.0
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8.0
    /usr/share/perl/5.8.0
    /usr/local/lib/site_perl


17 Oct 2002 01:10:11 -0400
Neil Conway <neilc@samurai.com>
Re: PL/Perl and Perl 5.8
On Thu, 2002-10-17 at 00:10, Neil Conway wrote:
> 
> 
> Well, I'm not happy with defining _GNU_SOURCE, but I don't agree that
> just saying "it's a Perl problem" is a good answer. That may well be
> the case, but it doesn't change the fact that a lot of people are
> running 5.8.0, and will probably continue to do so during the 7.3
> lifecycle[1]. We work around braindamage on other systems -- strictely
> speaking, we could say "the snprintf() bug with 64-bit Solaris is a
> Sun libc problem", for example.
> 
If you want to try it on my UnixWare 7.1.3 box, I can create an account
for you.  It has PERL 5.8.0 and a NON-gcc compiler.  PL/Perl from 7.2.2
works fine with it. 

I don't have the time, but can give anyone that wants it an account. 

(Peter Eisentraut already has such, and I'll create one for any that
want one).

The box is a 1.7Ghz P-4, and is on a 768K/768K DSL line.

LER
> Perhaps we can include a test for this in configure? (i.e. if
> --with-perl is specified, try compiling a simple XS file that exhibits
> the problem; if it fails, try it with -D_GNU_SOURCE).
> 
> Cheers,
> 
> Neil
> 
> [1] Note that I'm assuming that PL/Perl is broken with 5.8.0 on
> systems other than mine, and another person's on IRC who reported the
> problem to begin with. Can other people confirm the problem?
> 
> -- 
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
> 
> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
>   Platform:
>     osname=linux, osvers=2.4.19, archname=i386-linux-thread-multi
>     uname='linux cyberhq 2.4.19 #1 smp sun aug 4 11:30:45 pdt 2002 i686 unknown                                                                                                                                                  unknown gnulinux '
>     config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-f                                                                                                                                                 PIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.0 -Darchli                                                                                                                                                 b=/usr/lib/perl/5.8.0 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendora                                                                                                                                                 rch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.0                                                                                                                                                  -Dsitearch=/usr/local/lib/perl/5.8.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/u       !
    
>                                                                                                                                         sr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -U                                                                                                                                                 afs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.0 -Dd_dosuid                                                                                                                                                  -des'
>     hint=recommended, useposix=true, d_sigaction=define
>     usethreads=define use5005threads=undef useithreads=define usemultiplicity=de                                                                                                                                                 fine
>     useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
>     use64bitint=undef use64bitall=undef uselongdouble=undef
>     usemymalloc=n, bincompat5005=undef
>   Compiler:
>     cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing                                                                                                                                                  -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
>     optimize='-O3',
>     cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -I/usr/lo                                                                                                                                                 cal/include'
>     ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers                                                                                                                                                 =''
>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
>     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize                                                                                                                                                 =8
>     alignbytes=4, prototype=define
>   Linker and Libraries:
>     ld='cc', ldflags =' -L/usr/local/lib'
>     libpth=/usr/local/lib /lib /usr/lib
>     libs=-lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt
>     perllibs=-ldl -lm -lpthread -lc -lcrypt
>     libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so.5.8.0
>     gnulibc_version='2.2.5'
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
>     cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
> 
> 
> Characteristics of this binary (from libperl): 
>   Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_                                                                                                                                                 CONTEXT
>   Built under linux
>   Compiled at Sep 14 2002 17:36:21
>   @INC:
>     /etc/perl
>     /usr/local/lib/perl/5.8.0
>     /usr/local/share/perl/5.8.0
>     /usr/lib/perl5
>     /usr/share/perl5
>     /usr/lib/perl/5.8.0
>     /usr/share/perl/5.8.0
>     /usr/local/lib/site_perl
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


17 Oct 2002 00:17:04 -0500
Larry Rosenman <ler@lerctr.org>
Re: PL/Perl and Perl 5.8
Neil Conway <neilc@samurai.com> writes:
> Well, I'm not happy with defining _GNU_SOURCE, but I don't agree that
> just saying "it's a Perl problem" is a good answer. That may well be
> the case, but it doesn't change the fact that a lot of people are
> running 5.8.0, and will probably continue to do so during the 7.3
> lifecycle[1]. We work around braindamage on other systems -- strictely
> speaking, we could say "the snprintf() bug with 64-bit Solaris is a
> Sun libc problem", for example.

Well, I'm not opposed to a workaround in principle; I'm just unconvinced
that this is the right solution.  Do we understand what is broken and
why -D_GNU_SOURCE fixes it?

			regards, tom lane

Thu, 17 Oct 2002 08:45:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: PL/Perl and Perl 5.8 
Neil Conway writes:

> gcc -O2 -g -fpic -I. -I/usr/lib/perl/5.8.0/CORE -I../../../src/include   -c -o plperl.o plperl.c -MMD
> In file included from /usr/lib/perl/5.8.0/CORE/op.h:480,
>                  from /usr/lib/perl/5.8.0/CORE/perl.h:2209,
>                  from plperl.c:61:
> /usr/lib/perl/5.8.0/CORE/reentr.h:602: field `_crypt_struct' has incomplete type
> /usr/lib/perl/5.8.0/CORE/reentr.h:747: confused by earlier errors, bailing out
> make[3]: *** [plperl.o] Error 1

Can you post some snippets from the relevant code sections?  Following one
of the links that were posted I gathered that this is related to
crypt_r(), whose prototype is not exposed on my system unless you use
_GNU_SOURCE.  But I don't see any _crypt_struct here.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 17 Oct 2002 21:18:05 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: PL/Perl and Perl 5.8
Peter Eisentraut <peter_e@gmx.net> writes:
> Can you post some snippets from the relevant code sections?  Following one
> of the links that were posted I gathered that this is related to
> crypt_r(), whose prototype is not exposed on my system unless you use
> _GNU_SOURCE.  But I don't see any _crypt_struct here.

Yeah, the seems to be the culprit. Line 480 of reentr.h is part of the
definition of a monster struct; the relevent field is:

#ifdef HAS_CRYPT_R
#if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD
	CRYPTD* _crypt_data;
#else
	struct crypt_data _crypt_struct;
#endif
#endif /* HAS_CRYPT_R */

The "crypt_data" struct is defined in crypt.h, but only if _GNU_SOURCE
is defined -- just like crypt_r().

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


17 Oct 2002 16:46:36 -0400
Neil Conway <neilc@samurai.com>
Re: PL/Perl and Perl 5.8
Neil Conway writes:

> #ifdef HAS_CRYPT_R
> #if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD
> 	CRYPTD* _crypt_data;
> #else
> 	struct crypt_data _crypt_struct;
> #endif
> #endif /* HAS_CRYPT_R */
>
> The "crypt_data" struct is defined in crypt.h, but only if _GNU_SOURCE
> is defined -- just like crypt_r().

The HAS_CRYPT_R is true because the function is available even without the
prototype, but the struct is not.  A plain bug in Perl's configury
mechanism.

-- 
Peter Eisentraut   peter_e@gmx.net


Sat, 19 Oct 2002 00:06:32 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: PL/Perl and Perl 5.8
Peter Eisentraut <peter_e@gmx.net> writes:
> The HAS_CRYPT_R is true because the function is available even without the
> prototype, but the struct is not.  A plain bug in Perl's configury
> mechanism.

Yeah, that's true. The question is whether it's worth working around
the bug. IMHO, yes -- but what do other people think?

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


18 Oct 2002 18:36:21 -0400
Neil Conway <neilc@samurai.com>
Re: PL/Perl and Perl 5.8
Neil Conway wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > The HAS_CRYPT_R is true because the function is available even without the
> > prototype, but the struct is not.  A plain bug in Perl's configury
> > mechanism.
> 
> Yeah, that's true. The question is whether it's worth working around
> the bug. IMHO, yes -- but what do other people think?

With no motion on this, I assume we are going to call this a perl bug
and not work around it for 7.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

Tue, 5 Nov 2002 17:24:46 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: PL/Perl and Perl 5.8
On Dienstag, November 5, 2002, at 11:24  Uhr, Bruce Momjian wrote:

> Neil Conway wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> The HAS_CRYPT_R is true because the function is available even 
>>> without the
>>> prototype, but the struct is not.  A plain bug in Perl's configury
>>> mechanism.
>>
>> Yeah, that's true. The question is whether it's worth working around
>> the bug. IMHO, yes -- but what do other people think?
>
> With no motion on this, I assume we are going to call this a perl bug
> and not work around it for 7.3.

I've only just subscribed to this list, so I don't know all of the 
discussion
(given time, I'll look it up in the archives). But if you have found a 
perl
bug, particularly one of configuration, I'm sure the perl developers 
would
be grateful if you could report it to the perl5-porters list
(http://lists.perl.org/showlist.cgi?name=perl5-porters).

Or I could report it on your behalf, if you don't want to subscribe and
unsubscribe and all that.

Thank you,

Marcel


Wed, 6 Nov 2002 00:29:35 +0100
=?ISO-8859-1?Q?Marcel_Gr=FCnauer?= <marcel@uptime.at>
Re: PL/Perl and Perl 5.8
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> With no motion on this, I assume we are going to call this a perl bug
> and not work around it for 7.3.

Erm, no -- Reinhard Max already sent a fix for this to -patches, Tom
had an objection to it, and then Reinhard posted another version
(which presumably satisfies Tom's objections). It should probably be
in RC1...

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


05 Nov 2002 19:13:30 -0500
Neil Conway <neilc@samurai.com>
Re: PL/Perl and Perl 5.8
Marcel Grï¿½nauer <marcel@uptime.at> writes:
> I've only just subscribed to this list, so I don't know all of the
> discussion (given time, I'll look it up in the archives). But if you
> have found a perl bug, particularly one of configuration, I'm sure
> the perl developers would be grateful if you could report it to the
> perl5-porters list
> (http://lists.perl.org/showlist.cgi?name=perl5-porters).

Yes, it has already been reported to p5p. The first p5p thread on the
topic didn't contain any mention of a fix for the problem being
committed to the stable branch, but the Perl maintainers are aware of
it, at any rate, and may have fixed it in the interim.

Cheers,

Neil

-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC


05 Nov 2002 19:18:20 -0500
Neil Conway <neilc@samurai.com>
Re: PL/Perl and Perl 5.8
Neil Conway <neilc@samurai.com> writes:
> Erm, no -- Reinhard Max already sent a fix for this to -patches, Tom
> had an objection to it, and then Reinhard posted another version
> (which presumably satisfies Tom's objections).

Peter didn't like it ... which is about what I'd expected, but I was
keeping quiet till he weighed in ...

I'm guessing that what we need to do is -D_GNU_SOURCE somewhere in the
Makefiles; the $64 question is exactly where (can we restrict it to
src/pl/plperl?) and what conditions should cause the Makefiles to add
it?  Do we want a configure test?

FWIW, I see no such failure on HPUX with Perl 5.8.0, but that seems to
be because Perl's HAS_CRYPT_R symbol doesn't get set here.  Which is odd
in itself, because crypt_r() is definitely available on this platform.

			regards, tom lane

Tue, 05 Nov 2002 19:27:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: PL/Perl and Perl 5.8 
Tom Lane writes:

> I'm guessing that what we need to do is -D_GNU_SOURCE somewhere in the
> Makefiles; the $64 question is exactly where (can we restrict it to
> src/pl/plperl?) and what conditions should cause the Makefiles to add
> it?  Do we want a configure test?

The simplest choice would be to just define it unconditionally in linux.h.
Since it is not supposed to change any interfaces, just add new ones, this
should be safe.  If you don't believe that, then we really need to test
and define _GNU_SOURCE early in configure so the following tests can take
it into account.  In either case, the command line is not the place for
it.

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 6 Nov 2002 23:07:13 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: PL/Perl and Perl 5.8 
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I'm guessing that what we need to do is -D_GNU_SOURCE somewhere in the
>> Makefiles; the $64 question is exactly where

> The simplest choice would be to just define it unconditionally in linux.h.
> Since it is not supposed to change any interfaces, just add new ones, this
> should be safe.

That works for me.  The main issue in my mind is not to define it on
platforms that aren't glibc-based, but linux.h should be safe.

Any objections out there?

I see another potential problem BTW: pg_config.h has

#ifndef HAVE_INET_ATON
# include <sys/types.h>
# include <netinet/in.h>
# include <arpa/inet.h>
extern int inet_aton(const char *cp, struct in_addr * addr);
#endif

which it does *before* pulling in the port-specific config file.
While this won't break Linux since it has inet_aton(), I could see
problems arising on platforms without.  I am inclined to move all
the substitute "extern" declarations in pg_config.h to the bottom
of the file.

			regards, tom lane


Thu, 07 Nov 2002 13:21:31 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: PL/Perl and Perl 5.8 
On 10/18/02, Neil Conway <neilc@samurai.com> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > The HAS_CRYPT_R is true because the function is available even without the
> > prototype, but the struct is not.  A plain bug in Perl's configury
> > mechanism.
> 
> Yeah, that's true. The question is whether it's worth working around
> the bug. IMHO, yes -- but what do other people think?

this message spells out the problem & solution nicely:
  
http://mailman.cs.uchicago.edu/pipermail/swig-dev/2002-September/
008056.html

jr


> 
> -- 
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

-- 
------------------------------------------------------------
Joel W. Reed                                    412-257-3881
--------All the simple programs have been written.----------
Thu, 7 Nov 2002 14:42:29 -0500
"joel w. reed" <jreed@ddiworld.com>
Re: PL/Perl and Perl 5.8