Thread: building 7.4 with plperl
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
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.
Quoting Gianni Mariani <gianni@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
Quoting "Keith C. Perry" <netadmin@vcsn.com>: > Quoting Gianni Mariani <gianni@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
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
Quoting Gianni Mariani <gianni@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
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 peter_e@gmx.net