PL/Perl and Perl 5.8

PL/Perl and Perl 5.8

Post by Bruce Momji » Thu, 07 Nov 2002 07:25:04





> > 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

  +  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

 
 
 

PL/Perl and Perl 5.8

Post by Marcel Grünau » Thu, 07 Nov 2002 08:28:19





>>> 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


 
 
 

PL/Perl and Perl 5.8

Post by Neil Conw » Thu, 07 Nov 2002 09:13:40



> 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

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

 
 
 

PL/Perl and Perl 5.8

Post by Neil Conw » Thu, 07 Nov 2002 09:18:26



> 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

--

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

PL/Perl and Perl 5.8

Post by Tom La » Thu, 07 Nov 2002 09:27:11



> 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)---------------------------

 
 
 

PL/Perl and Perl 5.8

Post by Peter Eisentra » Fri, 08 Nov 2002 07:00:50


Quote: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.

--

---------------------------(end of broadcast)---------------------------

 
 
 

PL/Perl and Perl 5.8

Post by Tom La » Sat, 09 Nov 2002 03:22:09



> 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

message can get through to the mailing list cleanly

 
 
 

PL/Perl and Perl 5.8

Post by joel w. ree » Sun, 10 Nov 2002 00:27:03


--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable



> > 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.
>=20
> 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:
=20=20
http://mailman.cs.uchicago.edu/pipermail/swig-dev/2002-September/
008056.html

jr

>=20
> --=20

>=20
>=20
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

--=20
------------------------------------------------------------
Joel W. Reed                                    412-257-3881
--------All the simple programs have been written.----------

--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9ysIlx8bVY5wogAYRAsMrAJ9G2RIMHvtFetlD7RrTAJIhXCwx3QCg2G4k
ezB05aWPVoYCcBeLlAzfQ2c=
=6uEI
-----END PGP SIGNATURE-----

--ZPt4rx8FFjLCG7dd--

 
 
 

1. 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:


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

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

2. Any scripts for backup out there ?

3. Performance of c, pl/perl, pl/pgsql

4. Execute returns zero records affected when updating existing record

5. PL/PGSQL and PL/Perl time issues

6. two different databases

7. GA-Atlanta-238776--UNIX-Perl-EDI-AS400-Programmer-UNIX/Perl/EDI

8. PCs and Macs sharing databases - info request -

9. US-MN-: JAVA/PERL APPLICATION DEVELOPER - JAVA, PERL, ORACLE, UNIX

10. GA-Atlanta-97822--Perl-Visual Basic-Programmer-Visual Basic/Perl Script

11. CyberCash Perl scripts in Oracle Perl Catridge?

12. The Perl Clinic - Commercial Support for Perl and Oraperl

13. DB*PERL (was ora*perl) WHERE?