building 7.4 with plperl

[Gianni Mariani]

Before I go deep into this - does anyone have the quick fix for this ?

Some facts - the 7.3.4 version of plperl.c has the same errors in the
7.4 tree.
The 7.4 version of plperl.c (with some error handling API calls
commented out) compiles fine in the 7.3.4 tree.
(Same machine - same install of perl !) Points to using some alternate
perl API probably by macro collision ?
gcc -O2 -fno-strict-aliasing -fpic -I.
-I/usr/lib/perl5/5.6.1/i386-linux/CORE -I../../../src/include
-D_GNU_SOURCE -c -o plperl.o plperl.c
plperl.c: In function `plperl_create_ sub':
plperl.c:306: warning: passing arg 1 of `perl_call_pv' from incompatible
pointer type
plperl.c:306: warning: passing arg 2 of `perl_call_pv' makes pointer
from integer without a cast
plperl.c:306: error: too few arguments to function `perl_call_pv'
plperl.c:317: error: `thr' undeclared (first use in this function)
plperl.c:317: error: (Each undeclared identifier is reported only once
plperl.c:317: error: for each function it appears in.)
plperl.c: In function `plperl_call_pe rl_func':
plperl.c:425: warning: passing arg 1 of `perl_call_sv' from incompatible
pointer type
plperl.c:425: warning: passing arg 2 of `perl_call_sv' makes pointer
from integer without a cast
plperl.c:425: error: too few arguments to function `perl_call_sv'
plperl.c:437: error: `thr' undeclared (first use in this function)
plperl.c: In function `plperl_build_t uple_argument':
plperl.c:810: warning: passing arg 1 of `perl_eval_pv' from incompatible
pointer type
plperl.c:810: warning: passing arg 2 of `perl_eval_pv' makes pointer
from integer without a cast
plperl.c:810: error: too few arguments to function `perl_eval_pv'
make: *** [plperl.o] Error 1

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Gianni Mariani]

Gianni Mariani wrote:

Before I go deep into this - does anyone have the quick fix for this ?

Some facts - the 7.3.4 version of plperl.c has the same errors in the
7.4 tree.
The 7.4 version of plperl.c (with some error handling API calls
commented out) compiles fine in the 7.3.4 tree.
(Same machine - same install of perl !) Points to using some
alternate perl API probably by macro collision ?

/* Define to 1 to build client libraries as thread-safe code.
(--enable-thread-safety) */
#define USE_THREADS 1

So this seems to be the collision.

--enable-thread-safety is a new option for libpq - however this collides
with perl's use of the same macro.

I suspect that the right answer would be to change the name USE_THREADS
to PG_USE_THREADS for pg.

Quick and nasty work around patch:

--- plperl.c.7.4 Thu Sep 4 08:16:39 2003
+++ plperl.c Mon Nov 17 23:07:05 2003
@@ -55,6 +55,7 @@
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"

+#undef USE_THREADS
/* perl stuff */
#include "EXTERN.h"
#include "perl.h"

another fix would be to make plplerl use the explicit api.


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

[Keith C. Perry]

Quoting Gianni Mariani <gi****@mariani .ws>:

Gianni Mariani wrote:

Before I go deep into this - does anyone have the quick fix for this ?

Some facts - the 7.3.4 version of plperl.c has the same errors in the
7.4 tree.
The 7.4 version of plperl.c (with some error handling API calls
commented out) compiles fine in the 7.3.4 tree.
(Same machine - same install of perl !) Points to using some
alternate perl API probably by macro collision ?

/* Define to 1 to build client libraries as thread-safe code.
(--enable-thread-safety) */
#define USE_THREADS 1

So this seems to be the collision.

--enable-thread-safety is a new option for libpq - however this collides
with perl's use of the same macro.

I suspect that the right answer would be to change the name USE_THREADS
to PG_USE_THREADS for pg.

Quick and nasty work around patch:

--- plperl.c.7.4 Thu Sep 4 08:16:39 2003
+++ plperl.c Mon Nov 17 23:07:05 2003
@@ -55,6 +55,7 @@
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"

+#undef USE_THREADS
/* perl stuff */
#include "EXTERN.h"
#include "perl.h"

another fix would be to make plplerl use the explicit api.


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

I had this same issue as well but now I'm *slightly* concerned since most of my
code is perl. How soon would issue be reviewed? (not that I'm NOT going to use
your patch for right now).

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

_______________ _______________ ______
This email account is being host by:
VCSN, Inc : http://vcsn.com

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

http://archives.postgresql.org

[Keith C. Perry]

Quoting "Keith C. Perry" <ne******@vcsn. com>:

Quoting Gianni Mariani <gi****@mariani .ws>:

Gianni Mariani wrote:

Before I go deep into this - does anyone have the quick fix for this ?

Some facts - the 7.3.4 version of plperl.c has the same errors in the
7.4 tree.
The 7.4 version of plperl.c (with some error handling API calls
commented out) compiles fine in the 7.3.4 tree.
(Same machine - same install of perl !) Points to using some
alternate perl API probably by macro collision ?

/* Define to 1 to build client libraries as thread-safe code.
(--enable-thread-safety) */
#define USE_THREADS 1

So this seems to be the collision.

--enable-thread-safety is a new option for libpq - however this collides
with perl's use of the same macro.

I suspect that the right answer would be to change the name USE_THREADS
to PG_USE_THREADS for pg.

Quick and nasty work around patch:

--- plperl.c.7.4 Thu Sep 4 08:16:39 2003
+++ plperl.c Mon Nov 17 23:07:05 2003
@@ -55,6 +55,7 @@
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"

+#undef USE_THREADS
/* perl stuff */
#include "EXTERN.h"
#include "perl.h"

another fix would be to make plplerl use the explicit api.


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

I had this same issue as well but now I'm *slightly* concerned since most of
my
code is perl. How soon would issue be reviewed? (not that I'm NOT going to
use
your patch for right now).

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

I normally wouldn't reply to myself but I didn't have the original message. I
just built 7.4 on a Slackware 9.1 release with the following configure command:

../configure --enable-thread-safety --with-perl --with-openssl --with-tcl

I did not get any errors. The perl version was 5.8.0 and GCC version was 3.2.3

On the box that did get errors, it was perl 5.6.1 and gcc 2.95.3 (slackware 8.0
me thinks)

I hope this additional information helps.
--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

_______________ _______________ ______
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Gianni Mariani]

Keith C. Perry wrote:

I had this same issue as well but now I'm *slightly* concerned since most of my
code is perl. How soon would issue be reviewed? (not that I'm NOT going to use
your patch for right now).

I suspect that this is only an issue when you use
"--enable-thread-safety" which according to the release notes is only
for libpq and only fixes MT issues on connection start-up. So
theoretically, if you're using plperl in V7.3.4 or earlier, you simply
don't need "--enable-thread-safety" and so you may compile happily
without it. (That's the theory anyway).

This certainly needs to be addressed (patch or document) but it's not at
all an issue for someone migrating from an earlier release (not a
regression). I hope that you're slightly concerned *no more*.

G

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Keith C. Perry]

Quoting Gianni Mariani <gi****@mariani .ws>:

Keith C. Perry wrote:

I had this same issue as well but now I'm *slightly* concerned since most of

my

code is perl. How soon would issue be reviewed? (not that I'm NOT going to

use

your patch for right now).

I suspect that this is only an issue when you use
"--enable-thread-safety" which according to the release notes is only
for libpq and only fixes MT issues on connection start-up. So
theoretically, if you're using plperl in V7.3.4 or earlier, you simply
don't need "--enable-thread-safety" and so you may compile happily
without it. (That's the theory anyway).

This certainly needs to be addressed (patch or document) but it's not at
all an issue for someone migrating from an earlier release (not a
regression). I hope that you're slightly concerned *no more*.

G

I figured that much and yes I'm not concerned anymore but it does seem like it
might be version issue as well with perl and/or gcc since I did have a
successful compilation. I've got a project to move all my servers to Slackware
9.1 which will make this non-issue for me but for the original poster your patch
or omitting the "--enable-thread-safety" option look like equally good resolutions.

Thanks

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

_______________ _______________ ______
This email account is being host by:
VCSN, Inc : http://vcsn.com

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

[Peter Eisentraut]

Gianni Mariani writes:

The 7.4 version of plperl.c (with some error handling API calls
commented out) compiles fine in the 7.3.4 tree.
(Same machine - same install of perl !) Points to using some
alternate perl API probably by macro collision ?

/* Define to 1 to build client libraries as thread-safe code.
(--enable-thread-safety) */
#define USE_THREADS 1

So this seems to be the collision.

Fixed in 7.4 branch and current.

--
Peter Eisentraut pe*****@gmx.net
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly