Thread: 8.1RC1 fails to build on OS X (10.4)
Hello, uname -a: Darwin fulcrum.local 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh powerpc gcc --version: powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configuration options: --prefix=/Library/PostgreSQL \ --localstatedir=/var/db/pgsql \ --build=powerpc-apple-darwin8 \ --host=powerpc-apple-darwin8 \ --target=powerpc-apple-darwin8 \ --disable-debug \ --with-openssl \ --with-bonjour \ --with-java \ --enable-thread-safety Trying to build 8.1RC1 on the above configuration fails because it seems to have defined bool, but still doesn't seem to know what bool is. This causes it to fail the thread safety test during configuration and then bomb out during build with errors like these: /Users/idart/src/postgresql-8.1RC1/build/src/../../src/interfaces/ecpg/include/ecpglib.h:84: warning: data definition has no type or storage class /Users/idart/src/postgresql-8.1RC1/build/src/../../src/interfaces/ecpg/include/ecpglib.h:85: error: parse error before 'ECPGdescribe' /Users/idart/src/postgresql-8.1RC1/build/src/../../src/interfaces/ecpg/include/ecpglib.h:85: error: parse error before 'bool' /Users/idart/src/postgresql-8.1RC1/build/src/../../src/interfaces/ecpg/include/ecpglib.h:85: warning: type defaults to 'int' in declaration of 'ECPGdescribe' /Users/idart/src/postgresql-8.1RC1/build/src/../../src/interfaces/ecpg/include/ecpglib.h:85: warning: data definition has no type or storage class make[4]: *** [informix.o] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 The attached patches simply makes sure bool, true and false always gets defined on OS X. This fixes the problems, but I'm afraid it might be a bit naive as the patches don't consider OS X version, GCC version, or any other factors that migth impact the build. Not to mention that it might break things if the patched headers were included in a C++ program. I see that the build farm contains "tuna" with 10.4.2 and GCC 4.0, and apparently it builds just fine on that configuration (albeit without thread safety). If there are other solutions to this, I would appreciate it if someone could point me in the right direction. - IT --- src/include/c.h.orig 2005-10-15 04:49:41.000000000 +0200 +++ src/include/c.h 2005-11-02 10:44:07.000000000 +0100 @@ -178,15 +178,19 @@ #ifndef __cplusplus -#ifndef bool +#if defined(__APPLE__) && defined(__MACH__) +#define MACOSX +#endif + +#if !defined(bool) || defined(MACOSX) typedef char bool; #endif -#ifndef true +#if !defined(true) || defined(MACOSX) #define true ((bool) 1) #endif -#ifndef false +#if !defined(false) || defined(MACOSX) #define false ((bool) 0) #endif #endif /* not C++ */ --- src/interfaces/ecpg/include/ecpglib.h.orig 2005-11-02 11:01:05.000000000 +0100 +++ src/interfaces/ecpg/include/ecpglib.h 2005-11-02 12:01:50.000000000 +0100 @@ -9,19 +9,27 @@ #include "libpq-fe.h" #include "ecpgtype.h" #include <string.h> - #ifndef __BEOS__ +#ifndef C_H #ifndef __cplusplus -#ifndef bool -#define bool char + +#if defined(__APPLE__) && defined(__MACH__) +#define MACOSX +#endif + +#if !defined(bool) || defined(MACOSX) +typedef char bool; #endif /* ndef bool */ -#ifndef true +#if !defined(true) || defined(MACOSX) #define true ((bool) 1) #endif /* ndef true */ -#ifndef false + +#if !defined(false) || defined(MACOSX) #define false ((bool) 0) #endif /* ndef false */ + +#endif /* C_H */ #endif /* not C++ */ #else /* __BEOS__ */ #include <SupportDefs.h> --- src/interfaces/ecpg/pgtypeslib/extern.h.orig 2005-11-02 11:01:37.000000000 +0100 +++ src/interfaces/ecpg/pgtypeslib/extern.h 2005-11-02 12:03:14.000000000 +0100 @@ -37,10 +37,18 @@ char *pgtypes_alloc(long); char *pgtypes_strdup(char *); -#ifndef bool +#ifndef C_H + +#if defined(__APPLE__) && defined(__MACH__) +#define MACOSX +#endif + +#if !defined(bool) || defined(MACOSX) #define bool char #endif /* ndef bool */ +#endif /* ndef C_H */ + #ifndef FALSE #define FALSE 0 #endif /* FALSE */ --- src/tools/thread/thread_test.c.orig 2005-11-02 10:44:30.000000000 +0100 +++ src/tools/thread/thread_test.c 2005-11-02 10:40:44.000000000 +0100 @@ -24,15 +24,19 @@ #include "postgres.h" #else /* From src/include/c.h" */ -#ifndef bool +#if defined(__APPLE__) && defined(__MACH__) +#define MACOSX +#endif + +#if !defined(bool) || defined(MACOSX) typedef char bool; #endif -#ifndef true +#if !defined(true) || defined(MACOSX) #define true ((bool) 1) #endif -#ifndef false +#if !defined(false) || defined(MACOSX) #define false ((bool) 0) #endif #endif
Idar Tollefsen <idart@performancedesign.no> writes:
> Trying to build 8.1RC1 on the above configuration fails
OS X 10.4.what-exactly? And did you install the 10.4 Xcode tools?
PG builds fine for me on 10.4.2, and there's at least one 10.4.something
machine in the buildfarm, so it's not broken in general.
regards, tom lane
Tom Lane wrote: > OS X 10.4.what-exactly? And did you install the 10.4 Xcode tools? > PG builds fine for me on 10.4.2, and there's at least one 10.4.something > machine in the buildfarm, so it's not broken in general. With all due respect, please read my original posting again. uname output is there, indicating 10.4.3 (although I had the same problem with beta1 on 10.4.2), and the GCC --version output indicates that it's the Apple version of GCC, which is only installed with the Xcode package. Furthermore, it also states that I'm aware of the OS X machines in the build farm. - IT
Idar Tollefsen <idart@performancedesign.no> writes:
> Trying to build 8.1RC1 on the above configuration fails because it seems to have
> defined bool, but still doesn't seem to know what bool is.
Well, having just updated my laptop to 10.4.3, I tried it again, using
the same configure switches you mention ... and it still works fine for
me.
I notice however that you seem to have a different version of gcc:
> gcc --version:
> powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026)
> Copyright (C) 2005 Free Software Foundation, Inc.
Mine says
powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061)
Copyright (C) 2004 Free Software Foundation, Inc.
which is evidently older. Where'd you get yours from?
regards, tom lane
Tom Lane wrote: > I notice however that you seem to have a different version of gcc: > >>gcc --version: >>powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026) >>Copyright (C) 2005 Free Software Foundation, Inc. > > Mine says > > powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061) > Copyright (C) 2004 Free Software Foundation, Inc. > > which is evidently older. Where'd you get yours from? I believe 5026 came as part of the Xcode 2.1 package when I upgraded it from Xcode 2.0. Xcode et. al. can be downloaded from ADC (http://developer.apple.com/, choose "Log in"). The 4061 build you have, that came with Xcode 2.0, is a pre-release of GCC 4.0. The 5026 build is synchronized with the official 4.0 release. Good catch tough. Could you try the Xcode 2.1 upgrade and see if you get the same errors I'm seeing? Or could anyone tell us what GCC version "tuna" is running? - IT
On Wed, Nov 02, 2005 at 06:05:19PM +0100, Idar Tollefsen wrote: > Tom Lane wrote: > >I notice however that you seem to have a different version of gcc: > > > >>gcc --version: > >>powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build > >>5026) > >>Copyright (C) 2005 Free Software Foundation, Inc. > > > >Mine says > > > >powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. > >build 4061) > >Copyright (C) 2004 Free Software Foundation, Inc. > > > >which is evidently older. Where'd you get yours from? > > I believe 5026 came as part of the Xcode 2.1 package when I upgraded it > from Xcode 2.0. Xcode et. al. can be downloaded from ADC > (http://developer.apple.com/, choose "Log in"). > > The 4061 build you have, that came with Xcode 2.0, is a pre-release of GCC > 4.0. The 5026 build is synchronized with the official 4.0 release. > > Good catch tough. Could you try the Xcode 2.1 upgrade and see if you get > the same errors I'm seeing? Or could anyone tell us what GCC version "tuna" > is running? If tuna is upgraded to the latest version of the buildfarm script it will report config output even on sucessful builds, which will contain gcc info. IE: http://lnk.nu/pgbuildfarm.org/5ii.pl (search for 'configure:2078'). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> On Wed, Nov 02, 2005 at 06:05:19PM +0100, Idar Tollefsen wrote:
>> Good catch tough. Could you try the Xcode 2.1 upgrade and see if you get
>> the same errors I'm seeing? Or could anyone tell us what GCC version "tuna"
>> is running?
> If tuna is upgraded to the latest version of the buildfarm script it
> will report config output even on sucessful builds, which will contain
> gcc info.
That reminds me --- I was going to ask Andrew to pressure all the
buildfarm owners to update to current copies of the farm scripts.
Quite a lot of the machines are not reporting nearly as much info
as I would like to see.
regards, tom lane
Idar Tollefsen <idart@performancedesign.no> writes: > I believe 5026 came as part of the Xcode 2.1 package when I upgraded it from > Xcode 2.0. Xcode et. al. can be downloaded from ADC > (http://developer.apple.com/, choose "Log in"). Well, I updated to Xcode 2.1 and ... it still works. So that's not the explanation. I'm currently wondering if you have any nonstandard versions of system headers floating about, perhaps in /usr/local/include. regards, tom lane
> If tuna is upgraded to the latest version of the buildfarm script it > will report config output even on sucessful builds, which will contain > gcc info. IE: http://lnk.nu/pgbuildfarm.org/5ii.pl (search for > 'configure:2078'). She is apparently not. I can't find any stage logs in there. But thanks for the hint, I'll be sure to look for them in the future. - IT
Tom Lane wrote: > Well, I updated to Xcode 2.1 and ... it still works. So that's not the > explanation. I suppose it was a long shot. But thanks for the effort. > I'm currently wondering if you have any nonstandard versions of system > headers floating about, perhaps in /usr/local/include. Well... Yes and no. I do have some in /usr/pkg/include (pkgsrc from NetBSD), but that's not a location the compiler should pick up unless instructed to. I see tuna is using Fink, but I don't know what it's picking up from there. Readline? I'll fire up grep in the morning and search for headers defining bool, true and false. - IT
Idar Tollefsen <idart@performancedesign.no> writes:
> I'll fire up grep in the morning and search for headers defining bool,
> true and false.
Also it would be worth showing in more detail exactly what happens when
you try to build the (unpatched) sources.
regards, tom lane
Tom Lane wrote: > Also it would be worth showing in more detail exactly what happens when > you try to build the (unpatched) sources. *blush* Found it. Any one the following flags will produce the described problems (alone or in combination): -faltivec -mabi=altivec -maltivec -mcpu=<your CPU type here> I have these, and others, set because of other development work I do. And I always forget them when I just want to build something else. My bad. As a curious side note, MySQL (4.1.13a and pre-releases of 5.0) had trouble with the exact same flags. Other pieces of software I have compiled (CommonC++2, TAO, wxWidgets, bison, curl, OmniORB, Apache 2, etc., etc.) had no trouble with these, even if they were there unintentionally. - IT
Idar Tollefsen <idart@performancedesign.no> writes:
> *blush* Found it.
> Any one the following flags will produce the described problems (alone
> or in combination):
> -faltivec
> -mabi=altivec
> -maltivec
> -mcpu=<your CPU type here>
<spock>Fascinating.</spock>
I tried this on my own machine, and found out that -faltivec causes
Darwin's gcc to add about a dozen predefined macros (compare -dM output
with and without it). The gem that's killing us is
#define bool bool
but it tromps on user identifier space in some other ways too, including
#define'ing "pixel" and "vector".
I cannot imagine any sane use for a macro defined as above, so I'd
suggest filing a bug report with Apple.
We could kluge our way around this with something like#ifdef __APPLE_CC__#undef bool#endif
in c.h, but I'm a little worried what impact this might have on the
system header files. Why in the world have they got it doing that?
Meanwhile, this is a good tip to have in our archives.
regards, tom lane
Tuna is running Dave-Cramers-Computer:~ davec$ uname -a Darwin Dave-Cramers-Computer.local 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc gcc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061) On 2-Nov-05, at 1:57 PM, Jim C. Nasby wrote: > On Wed, Nov 02, 2005 at 06:05:19PM +0100, Idar Tollefsen wrote: > >> Tom Lane wrote: >> >>> I notice however that you seem to have a different version of gcc: >>> >>> >>>> gcc --version: >>>> powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, >>>> Inc. build >>>> 5026) >>>> Copyright (C) 2005 Free Software Foundation, Inc. >>>> >>> >>> Mine says >>> >>> powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple >>> Computer, Inc. >>> build 4061) >>> Copyright (C) 2004 Free Software Foundation, Inc. >>> >>> which is evidently older. Where'd you get yours from? >>> >> >> I believe 5026 came as part of the Xcode 2.1 package when I >> upgraded it >> from Xcode 2.0. Xcode et. al. can be downloaded from ADC >> (http://developer.apple.com/, choose "Log in"). >> >> The 4061 build you have, that came with Xcode 2.0, is a pre- >> release of GCC >> 4.0. The 5026 build is synchronized with the official 4.0 release. >> >> Good catch tough. Could you try the Xcode 2.1 upgrade and see if >> you get >> the same errors I'm seeing? Or could anyone tell us what GCC >> version "tuna" >> is running? >> > > If tuna is upgraded to the latest version of the buildfarm script it > will report config output even on sucessful builds, which will contain > gcc info. IE: http://lnk.nu/pgbuildfarm.org/5ii.pl (search for > 'configure:2078'). > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > >