By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,807 Members | 1,995 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,807 IT Pros & Developers. It's quick & easy.

building 7.4 with plperl

P: n/a

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_perl_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_tuple_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*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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

Nov 12 '05 #2

P: n/a
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

Nov 12 '05 #3

P: n/a
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

Nov 12 '05 #4

P: n/a
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

Nov 12 '05 #5

P: n/a
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

Nov 12 '05 #6

P: n/a
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*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.