plperl failure on OS X 10.5(.1)

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=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-arch i386 -arch ppc -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, but we can't
be sure _G_config.h will be included before this file. _G_config.h
also defines _G_HAVE_BOOL for both gcc and 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

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