Обсуждение: plperl failure on OS X 10.5(.1)
I mentioned in #postgres a bit ago to no avail that I couldn't get my plperl stored procedures to work after upgrading to OS X 10.5, with only a obtuse "ERROR: null prosrc". I was using 8.2.4 and didn't want to make a big deal about a non-current release, but today I had a chance to build 8.3 and 8.2.5 and am seeing the same behavior. I don't see 10.5 in the build farm list, so I thought I would ask if this is a known issue. A synopsis: configure, make and install a fresh postgres and database (configured --with-perl --with-python --with-openssl). This is on my G4 powerbook. createlang pgperl attempt to create a perl function, e.g. the perl_max function from the docs (http://www.postgresql.org/docs/8.2/static/plperl-funcs.html): $ cat perlmax.pl.sql CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $$ if ($_[0] > $_[1]) { return $_[0]; } return $_[1]; $$ LANGUAGE plperl; $ ~/local/pg-8.3b3/bin/psql -f perlmax.pl.sql test psql:perlmax.pl.sql:4: ERROR: null prosrc there were a few warnings building plperl: gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels-fno-strict-aliasing -I. -I../../../src/include -I/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE -c -o plperl.c: In function '_PG_initg: plperl.c:191: warning: passing argument 4 of 'DefineCustomBoolVariableg from incompatible pointer type plperl.c: In function 'compile_plperl_functiong: plperl.c:1624: warning: passing argument 4 of 'SysCacheGetAttrg from incompatible pointer type plperl.c:1652: warning: passing argument 4 of 'hash_searchg from incompatible pointer type plperl.c: In function 'plperl_hash_from_tupleg: plperl.c:1685: warning: passing argument 4 of 'nocachegetattrg from incompatible pointer type plperl.c:1685: warning: passing argument 4 of 'nocachegetattrg from incompatible pointer type plperl.c:1685: warning: passing argument 4 of 'heap_getsysattrg from incompatible pointer type plperl.c:1696: warning: passing argument 3 of 'getTypeOutputInfog from incompatible pointer type plperl.c: In function 'plperl_return_nextg: plperl.c:1926: warning: passing argument 3 of 'heap_form_tupleg from incompatible pointer type plperl.c: In function 'plperl_spi_prepareg: plperl.c:2229: warning: passing argument 4 of 'hash_searchg from incompatible pointer type nothing fatal... and a more worrisome warning when linking libperl: gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels-fno-strict-aliasing -bundle -multiply_defined suppress plperl.o spi_internal.o SPI.o -L/usr/local/lib -L/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE-L../../../src/port -arch i386 -arch ppc /System/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a-lperl -ldl -lm -lutil -lc -bundle_loader../../../src/backend/postgres -o libplperl.0.0.so ld: warning in ../../../src/backend/postgres, file is not of required architecture ld: warning in plperl.o, file is not of required architecture ld: warning in spi_internal.o, file is not of required architecture ld: warning in SPI.o, file is not of required architecture I don't have terribly much time to figure out the guts of plperl, but would be glad to provide any more information or a login to an OS 10.5 host if that can help... Thanks for everything, -- Brandon Maust, Research Consultant Mullins Lab, University of Washington School of Medicine
B. Maust wrote: > there were a few warnings building plperl: > > gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -I. > -I../../../src/include > -I/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE -c -o > plperl.c: In function '_PG_initg: > plperl.c:191: warning: passing argument 4 of 'DefineCustomBoolVariableg > from incompatible pointer type > plperl.c: In function 'compile_plperl_functiong: > plperl.c:1624: warning: passing argument 4 of 'SysCacheGetAttrg from > incompatible pointer type > plperl.c:1652: warning: passing argument 4 of 'hash_searchg from > incompatible pointer type > plperl.c: In function 'plperl_hash_from_tupleg: plperl.c:1685: warning: > passing argument 4 of 'nocachegetattrg from incompatible pointer type > plperl.c:1685: warning: passing argument 4 of 'nocachegetattrg from > incompatible pointer type > plperl.c:1685: warning: passing argument 4 of 'heap_getsysattrg from > incompatible pointer type > plperl.c:1696: warning: passing argument 3 of 'getTypeOutputInfog from > incompatible pointer type > plperl.c: In function 'plperl_return_nextg: > plperl.c:1926: warning: passing argument 3 of 'heap_form_tupleg from > incompatible pointer type > plperl.c: In function 'plperl_spi_prepareg: > plperl.c:2229: warning: passing argument 4 of 'hash_searchg from > incompatible pointer type > > nothing fatal... and a more worrisome warning when linking libperl: Nothing fatal? Huh, you have a curious idea about warnings. This makes me think you have the wrong headers or something -- the argument mentioned in all these cases is bool, so maybe there is an ABI incompatibility somewhere. Perhaps a Perl header is redefining "bool" on your platform? -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "I love the Postgres community. It's all about doing things _properly_. :-)" (David Garamond)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Nothing fatal? Huh, you have a curious idea about warnings. This makes
> me think you have the wrong headers or something -- the argument
> mentioned in all these cases is bool, so maybe there is an ABI
> incompatibility somewhere.
Yeah, and it's hardly difficult to see how that might lead to the
reported "null prosrc" error, either.
bool isnull; ... prosrcdatum = SysCacheGetAttr(PROCOID, procTup,
Anum_pg_proc_prosrc, &isnull); if (isnull) elog(ERROR, "null prosrc");
> Perhaps a Perl header is redefining "bool" on your platform?
Seems the question is not so much about OS X as it is about what
perl you're using ...
regards, tom lane
On 21 Nov, 2007, at 08:39 , Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Nothing fatal? Huh, you have a curious idea about warnings. This
>> makes
>> me think you have the wrong headers or something -- the argument
>> mentioned in all these cases is bool, so maybe there is an ABI
>> incompatibility somewhere.
>
> Yeah, and it's hardly difficult to see how that might lead to the
> reported "null prosrc" error, either.
>
> bool isnull;
> ...
> prosrcdatum = SysCacheGetAttr(PROCOID, procTup,
> Anum_pg_proc_prosrc, &isnull);
> if (isnull)
> elog(ERROR, "null prosrc");
>
>> Perhaps a Perl header is redefining "bool" on your platform?
>
> Seems the question is not so much about OS X as it is about what
> perl you're using ...
it's 5.8.8, as provided by apple (same for gcc, etc):
$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=darwin, osvers=9.0,
archname=darwin-thread-multi-2level uname='darwin omen.apple.com 9.0 darwin kernel version 9.0.0b5:
mon sep 10 17:17:11 pdt 2007; root:xnu-1166.6~1release_ppc power
macintosh ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=-
Dman3ext=3pm -Duseithreads -Duseshrplib' hint=recommended, useposix=true, d_sigaction=define usethreads=define
use5005threads=undefuseithreads=define
usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define
use64bitall=defineuselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-arch i386
-archppc -g -pipe -fno-common -
DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -Wdeclaration-after-
statement -I/usr/local/include', optimize='-O3', cppflags='-no-cpp-precomp -g -pipe -fno-common -DPERL_DARWIN
-no-
cpp-precomp -fno-strict-aliasing -Wdeclaration-after-statement -I/usr/
local/include' ccversion='', gccversion='4.0.1 (Apple Inc. build 5465)',
gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8,
d_longdbl=define,longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc
-mmacosx-version-min=10.5',ldflags ='-arch i386 -arch ppc
-L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true,
libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef,
ccdlflags='' cccdlflags=' ', lddlflags='-arch i386 -arch ppc -bundle -
undefined dynamic_lookup -L/usr/local/lib'
Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under
darwin Compiled at Sep 23 2007 19:07:53
the worrisome "not required architecture" warning drops out from the
link if I exclude the '-arch i386', so at least that one's probably
ignorable. Doing so makes a binary different libplperl, but doesn't
seem to change the end result.
perl on OS X does look to be constitutively defining a 'bool' as _Bool
via gcc's stdbool.h, so perhaps this is more of a compiler issue? OS X
10.5.1 uses gcc 4.0.1.
--
Brandon
Brandon Maust <bmaust@u.washington.edu> writes:
> On 21 Nov, 2007, at 08:39 , Tom Lane wrote:
>> Seems the question is not so much about OS X as it is about what
>> perl you're using ...
> it's 5.8.8, as provided by apple (same for gcc, etc):
> perl on OS X does look to be constitutively defining a 'bool' as _Bool
> via gcc's stdbool.h, so perhaps this is more of a compiler issue?
No, because I see the identical content in stdbool.h on OS X 10.4
(perl 5.8.6) and it is not causing a problem here. Apparently 5.8.8
is sucking stdbool.h into the compile where 5.8.6 did not. Can you
track down just what the inclusion path is?
I'm tempted to fix this with
#ifdef bool
#undef bool
#endif
in plperl.h after pulling in the Perl headers. However, it's not clear
to me why you aren't seeing warnings about "false" and "true" getting
redefined, if stdbool.h is really getting included.
For reference, the interesting part of stdbool.h on 10.4 looks like
#define false 0
#define true 1
#define bool _Bool
#if __STDC_VERSION__ < 199901L && __GNUC__ < 3
typedef int _Bool;
#endif
Since this is gcc 3, I suppose that the typedef isn't being used here
but must get supplied internally by the compiler...
regards, tom lane
On 21 Nov, 2007, at 10:50 , Tom Lane wrote: > Brandon Maust <bmaust@u.washington.edu> writes: >> On 21 Nov, 2007, at 08:39 , Tom Lane wrote: >>> Seems the question is not so much about OS X as it is about what >>> perl you're using ... > >> it's 5.8.8, as provided by apple (same for gcc, etc): > >> perl on OS X does look to be constitutively defining a 'bool' as >> _Bool >> via gcc's stdbool.h, so perhaps this is more of a compiler issue? > > No, because I see the identical content in stdbool.h on OS X 10.4 > (perl 5.8.6) and it is not causing a problem here. Apparently 5.8.8 > is sucking stdbool.h into the compile where 5.8.6 did not. Can you > track down just what the inclusion path is? yes, it is sucking it in (via handy.h), at least in 10.5: /* XXX Configure ought to have a test for a boolean type, if I can just figure out all the headers such a test needs. Andy Dougherty August 1996 */ /* bool is built-in for g++-2.6.3 and later, which might be used for extensions. <_G_config.h> defines _G_HAVE_BOOL, butwe can't be sure _G_config.h will be included before this file. _G_config.h also defines _G_HAVE_BOOL for both gccand g++, but only g++ actually has bool. Hence, _G_HAVE_BOOL is pretty useless for us. g++ can be identified by __GNUG__. Andy Dougherty February 2000 */ #if 1 /* always on Mac OS X */ # include <stdbool.h> # ifndef HAS_BOOL # define HAS_BOOL 1 # endif #endif > I'm tempted to fix this with > > #ifdef bool > #undef bool > #endif > > in plperl.h after pulling in the Perl headers. However, it's not > clear > to me why you aren't seeing warnings about "false" and "true" getting > redefined, if stdbool.h is really getting included. > > For reference, the interesting part of stdbool.h on 10.4 looks like > > #define false 0 > #define true 1 > > #define bool _Bool > #if __STDC_VERSION__ < 199901L && __GNUC__ < 3 > typedef int _Bool; > #endif > > Since this is gcc 3, I suppose that the typedef isn't being used here > but must get supplied internally by the compiler... stdbool.h looks the same in 10.5. -- Brandon
I wrote:
> Apparently 5.8.8
> is sucking stdbool.h into the compile where 5.8.6 did not. Can you
> track down just what the inclusion path is?
I pulled down the perl 5.8.8 sources and cannot find a reference to
stdbool.h anywhere. What I do find is that "handy.h" defines what
Perl thinks bool is:
#ifndef HAS_BOOL
# if defined(UTS) || defined(VMS)
# define bool int
# else
# define bool char
# endif
# define HAS_BOOL 1
#endif
On OSX 10.4 this file is installed in
/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE/handy.h
Would you look at what 10.5 has? I suspect that Apple has modified
their version to force bool to be int as of 10.5.
regards, tom lane
Brandon Maust <bmaust@u.washington.edu> writes:
> yes, it is sucking it in (via handy.h), at least in 10.5:
> #if 1 /* always on Mac OS X */
> # include <stdbool.h>
> # ifndef HAS_BOOL
> # define HAS_BOOL 1
> # endif
> #endif
Nasty. I'm still surprised that there's no redefinition warning for
"false" and "true", but that's not too important, since the cast to
(bool) isn't really critical. I guess what we need is as attached;
would you try it and see?
How far back should we patch this? Is anyone likely to care about
pre-8.2 plperl on Leopard?
Another thought here is that c.h tries to cater to the possibility
of bool being #define'd by system headers, but if that did actually
happen anywhere then this patch would fail. We'd have pretty serious
problems anyway if bool were not char-size, since pg_type.h hardwires
its size as 1 byte. So I'm a bit tempted to remove the "#ifndef bool"
from c.h, or else make it do "#undef bool". Comments?
regards, tom lane
*** src/pl/plperl/plperl.h.orig Fri Jan 5 17:20:01 2007
--- src/pl/plperl/plperl.h Wed Nov 21 14:31:54 2007
***************
*** 38,43 ****
--- 38,48 ----
#define pTHX void
#endif
+ /* perl may have a different width of "bool", don't buy it */
+ #ifdef bool
+ #undef bool
+ #endif
+
/* routines from spi_internal.c */
int spi_DEBUG(void);
int spi_LOG(void);
On 21 Nov, 2007, at 11:38 , Tom Lane wrote: > Brandon Maust <bmaust@u.washington.edu> writes: >> yes, it is sucking it in (via handy.h), at least in 10.5: > >> #if 1 /* always on Mac OS X */ >> # include <stdbool.h> >> # ifndef HAS_BOOL >> # define HAS_BOOL 1 >> # endif >> #endif > > Nasty. I'm still surprised that there's no redefinition warning for > "false" and "true", but that's not too important, since the cast to > (bool) isn't really critical. I guess what we need is as attached; > would you try it and see? yep, fixes it for me with 8.2.5 and 8.3b3. everything works even allowing that -arch warning, but it's not the clean compiling experience I'm used to from postgresql... Thanks, Tom. -- Brandon