Re: [HACKERS] PL/Perl and Perl 5.8
On 10/18/02, Neil Conway [EMAIL PROTECTED] wrote: Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Joel W. Reed412-257-3881 All the simple programs have been written.-- msg24938/pgp0.pgp Description: PGP signature
Re: [HACKERS] PL/Perl and Perl 5.8
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl and Perl 5.8
On Dienstag, November 5, 2002, at 11:24 Uhr, Bruce Momjian wrote: Neil Conway wrote: Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PL/Perl and Perl 5.8
Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PL/Perl and Perl 5.8
Marcel Grünauer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PL/Perl and Perl 5.8
Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl and Perl 5.8
Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 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:[EMAIL PROTECTED]/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 [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PL/Perl and Perl 5.8
Neil Conway [EMAIL PROTECTED] 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:[EMAIL PROTECTED]/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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/Perl and Perl 5.8
Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] 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 [EMAIL PROTECTED] || 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
