Thread: 8.1RC1 fails to build on OS X (10.4)

8.1RC1 fails to build on OS X (10.4)

From
Idar Tollefsen
Date:
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

Re: 8.1RC1 fails to build on OS X (10.4)

From
Tom Lane
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Idar Tollefsen
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Tom Lane
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Idar Tollefsen
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
"Jim C. Nasby"
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Tom Lane
Date:
"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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Tom Lane
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Idar Tollefsen
Date:
> 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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Idar Tollefsen
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Tom Lane
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Idar Tollefsen
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Tom Lane
Date:
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


Re: 8.1RC1 fails to build on OS X (10.4)

From
Dave Cramer
Date:
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
>
>