Thread: PL/Perl and Perl 5.8

PL/Perl and Perl 5.8

From
Neil Conway
Date:
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



Re: PL/Perl and Perl 5.8

From
Tom Lane
Date:
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


Re: PL/Perl and Perl 5.8

From
Neil Conway
Date:
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
 



Re: PL/Perl and Perl 5.8

From
Larry Rosenman
Date:
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



Re: PL/Perl and Perl 5.8

From
Tom Lane
Date:
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


Re: PL/Perl and Perl 5.8

From
Peter Eisentraut
Date:
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



Re: PL/Perl and Perl 5.8

From
Neil Conway
Date:
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_CCDCRYPTD* _crypt_data;
#elsestruct 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



Re: PL/Perl and Perl 5.8

From
Peter Eisentraut
Date:
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



Re: PL/Perl and Perl 5.8

From
Neil Conway
Date:
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



Re: PL/Perl and Perl 5.8

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: PL/Perl and Perl 5.8

From
Marcel Grünauer
Date:
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



Re: PL/Perl and Perl 5.8

From
Neil Conway
Date:
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



Re: PL/Perl and Perl 5.8

From
Neil Conway
Date:
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



Re: PL/Perl and Perl 5.8

From
Tom Lane
Date:
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


Re: PL/Perl and Perl 5.8

From
Peter Eisentraut
Date:
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



Re: PL/Perl and Perl 5.8

From
Tom Lane
Date:
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



Re: PL/Perl and Perl 5.8

From
"joel w. reed"
Date:
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.----------