Обсуждение: PL/Perl and Perl 5.8
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.----------