Обсуждение: Can't Build 7.3.4 on OS X
I cannot build the latest release on OS X Jaguar.
Any ideas? Details below...
Running GCC 3.3 from Apple:
hunter% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1435)
Did just a vanilla './configure' and then make:
hunter% make
make -C doc all
gzip -d -c man.tar.gz | /usr/bin/tar xf -
for file in man1/*.1; do \
mv $file $file.bak && \
sed -e 's/\\fR(l)/\\fR(7)/' $file.bak >$file && \
rm -f $file.bak || exit; \
done
/bin/sh ../config/mkinstalldirs man7
mkdir man7
for file in manl/*.l; do \
sed -e '/^\.TH/s/"l"/"7"/' \
-e 's/\\fR(l)/\\fR(7)/' \
$file >man7/`basename $file | sed 's/.l$/.7/'` || exit; \
done
make -C src all
make -C port all
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../src/include -c -o isinf.o isinf.c
In file included from /usr/include/math.h:24,
from isinf.c:5:
/usr/include/architecture/ppc/math.h:128: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:128: error: parse error before
"__cplusplus"
/usr/include/architecture/ppc/math.h:129: error: syntax error before
"inline"
/usr/include/architecture/ppc/math.h:130: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:130: error: parse error before "else"
/usr/include/architecture/ppc/math.h:131: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:132: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:140: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:140: error: parse error before
"__cplusplus"
/usr/include/architecture/ppc/math.h:141: error: syntax error before
"inline"
/usr/include/architecture/ppc/math.h:142: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:142: error: parse error before "else"
/usr/include/architecture/ppc/math.h:143: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:144: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:151: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:151: error: parse error before
"__cplusplus"
/usr/include/architecture/ppc/math.h:152: error: syntax error before
"inline"
/usr/include/architecture/ppc/math.h:153: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:153: error: parse error before "else"
/usr/include/architecture/ppc/math.h:154: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:155: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:163: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:163: error: parse error before
"__cplusplus"
/usr/include/architecture/ppc/math.h:164: error: syntax error before
"inline"
/usr/include/architecture/ppc/math.h:165: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:165: error: parse error before "else"
/usr/include/architecture/ppc/math.h:166: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:167: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:175: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:175: error: parse error before
"__cplusplus"
/usr/include/architecture/ppc/math.h:176: error: syntax error before
"inline"
/usr/include/architecture/ppc/math.h:177: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:177: error: parse error before "else"
/usr/include/architecture/ppc/math.h:178: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:179: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:187: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:187: error: parse error before
"__cplusplus"
/usr/include/architecture/ppc/math.h:188: error: syntax error before
"inline"
/usr/include/architecture/ppc/math.h:189: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:189: error: parse error before "else"
/usr/include/architecture/ppc/math.h:190: error: syntax error at '#' token
/usr/include/architecture/ppc/math.h:191: error: syntax error at '#' token
make[2]: *** [isinf.o] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2
Hunter Hillegas <lists@lastonepicked.com> writes:
> I cannot build the latest release on OS X Jaguar.
> gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../src/include -c -o isinf.o isinf.c
> In file included from /usr/include/math.h:24,
> from isinf.c:5:
> /usr/include/architecture/ppc/math.h:128: error: syntax error at '#' token
Hmph. It builds just fine on OS X for me, or at least it did last week
(my Mac laptop is now in the shop, sob). Which OS X release have you
got, exactly? Does it help if you take out -traditional-cpp ?
regards, tom lane
>> Is there an easy way to remove 'traditional-cpp' from the whole build?
> See src/template/darwin. Whatever change is needed, it probably will be
> in that file or src/makefiles/Makefile.darwin (or possibly
> src/include/port/darwin.h). Let us know what you find out ...
BTW: the template file is an input to configure, so you must rerun
configure if you change it. The other two files are live, you can just
edit 'em and rebuild.
regards, tom lane
Hunter Hillegas <lists@lastonepicked.com> writes:
> Jaguar 10.2.6.
Okay, I think I was still on 10.2.4. I won't be able to try 10.2.6 till
my laptop gets fixed.
> Is there an easy way to remove 'traditional-cpp' from the whole build?
See src/template/darwin. Whatever change is needed, it probably will be
in that file or src/makefiles/Makefile.darwin (or possibly
src/include/port/darwin.h). Let us know what you find out ...
regards, tom lane
Jaguar 10.2.6. The differences is most likely the latest compilers, GCC 3.3 from Apple. You can get them from their developer site. Supposedly the new compiler generates MUCH better PPC code, so I was hoping to use it. Is there an easy way to remove 'traditional-cpp' from the whole build? Thanks, Hunter > From: Tom Lane <tgl@sss.pgh.pa.us> > Date: Mon, 28 Jul 2003 01:40:50 -0400 > To: Hunter Hillegas <lists@lastonepicked.com> > Cc: PostgreSQL <pgsql-general@postgresql.org> > Subject: Re: [GENERAL] Can't Build 7.3.4 on OS X > > Hmph. It builds just fine on OS X for me, or at least it did last week > (my Mac laptop is now in the shop, sob). Which OS X release have you > got, exactly? Does it help if you take out -traditional-cpp ? > > regards, tom lane
Changing to -no-cpp-precomp for Darwin allows the build to complete but there are a LOT of errors. Just starting to get in there to see how it runs. Hunter > From: Tom Lane <tgl@sss.pgh.pa.us> > Date: Mon, 28 Jul 2003 13:47:20 -0400 > To: Hunter Hillegas <lists@lastonepicked.com> > Cc: PostgreSQL <pgsql-general@postgresql.org> > Subject: Re: [GENERAL] Can't Build 7.3.4 on OS X > > Hunter Hillegas <lists@lastonepicked.com> writes: >> Jaguar 10.2.6. > > Okay, I think I was still on 10.2.4. I won't be able to try 10.2.6 till > my laptop gets fixed. > >> Is there an easy way to remove 'traditional-cpp' from the whole build? > > See src/template/darwin. Whatever change is needed, it probably will be > in that file or src/makefiles/Makefile.darwin (or possibly > src/include/port/darwin.h). Let us know what you find out ... > > regards, tom lane
Hunter Hillegas <lists@lastonepicked.com> writes:
> I cannot build the latest release on OS X Jaguar.
> Running GCC 3.3 from Apple:
It seems "-traditional-cpp" has become nontraditional in 3.3. Or
possibly Apple changed their system header files in a way that broke
that preprocessor. What's certain is that gcc 3.3 rejects some of
the Darwin header files when using -traditional-cpp. This is not our
fault ;-).
It seems to work okay if you change -traditional-cpp to -no-cpp-precomp
in src/template/darwin (you will need to rerun configure afterwards).
Experimenting, I find that Apple's gcc 3.1 and 3.3 both build PG fine
with that switch. Their latest update of gcc 2.95 no longer seems to
work at all (it generates invalid assembler code for xlog.c).
I tried removing the cpp option entirely, but that blew up in other
places, and I have no interest in figuring out why just now.
Is anyone on the list still running OS X 10.1, or anyway still using a
version of the OS X developer tools older than the Dec 2002 release?
It would be good to check if -no-cpp-precomp creates any problems on
any release that anyone still cares about. For the moment, I've made
src/template/darwin unconditionally use -no-cpp-precomp, but we could
probably hack it to use -traditional-cpp if there's still any interest
in Darwin compiler versions that don't recognize -no-cpp-precomp.
regards, tom lane
Marko Karppinen <karppinen@pobox.com> writes:
> On lauantai, syys 20, 2003, at 23:37 Europe/Helsinki, Tom Lane wrote:
>> Is anyone on the list still running OS X 10.1, or anyway still using a
>> version of the OS X developer tools older than the Dec 2002 release?
> -no-cpp-precomp replaced -traditional-cpp as the preferred syntax
> for turning off the precompiled header support in Mac OS X 10.1
> (Darwin 5.0).
Great. I was afraid it might have been new with 10.2.
> Supporting Mac OS X 10.0 (Darwin 1.x) would require
> -traditional-cpp, but I don't think it's necessary.
I agree. Thanks for the info.
BTW, is anyone interested in looking into whether we can be made to
build without using either flag? I tried it and saw a number of
failures that looked like they traced to incompatible macro expansion.
This wouldn't surprise me if PG were some halfbaked package that only
got tested with stock GCC, but considering that we actually build fine
on quite a range of compilers, it seems like Apple's cpp ought to work
too. It would be interesting to understand what the problem is.
regards, tom lane
On Sep 21, 2003, at 3:11 PM, Tom Lane wrote:
> BTW, is anyone interested in looking into whether we can be made to
> build without using either flag? I tried it and saw a number of
I did this... before I knew about -no-cpp-precomp. :( I read all
about -traditional-cpp in the gcc man page, but could never find the
corresponding "not traditional cpp" flag.
It boiled down to two things: use of macros that used the
"stringification" syntax, and whitespace around marco arguments.
Take src/include/nodes/nodes.h, around line 265 for example:
#define makeNode(_type_) ((_type_ *) newNode(sizeof(_type_),T_#_type_))
...
#define IsA(nodeptr, _type_) (nodeTag(nodeptr) == T_#_type_)
gcc 3.3 just didn't like this. So I had to fake it out:
#define T_UNDER() T_
#define makeNode(_type_) ((_type_ *)
newNode(sizeof(_type_),T_UNDER()_type_))
...
#define IsA(nodeptr,_type_) (nodeTag(nodeptr) == T_UNDER()_type_)
But it gets better. Apparently with gcc 3.3 whitespace around macro
arguments is preserved! So, in the case of calls to (at least) the IsA
macro:
before: if (IsA(foo, Short))
after: if (IsA(foo,Short))
^----------------- no space!
From what I could tell, the statement would be expanded into (using my
re-defined version above):
if (nodeTag(nodeptr) == T_ Short)
which of course isn't legal syntax b/c of the space.
So I went through with some Perl and did a bunch of global
substitutions on the files that gcc complained about. There were a few
more than the above examples, but not too many.
> too. It would be interesting to understand what the problem is.
There it is.
eric
On Sep 21, 2003, at 3:11 PM, Tom Lane wrote: > Great. I was afraid it might have been new with 10.2. Also, 7.3.4 doesn't link on the OS X 10.3 beta's. Apparently tas is never being defined. I could never fix this. In the list archives I found all sorts of references to tas()/TAS and older versions of postgres on other operating systems, but I simply couldn't figure out how to make it happen on OS X 10.3. the #if defined(__APPLE__) || defined(__ppc__) section of s_lock.c was being used, as best I could tell. It defines a method named "void tas_dummy()". And s_lock.h declares "extern int tas(slock_t *lock)" and "#define TAS(lock) tas(lock)".... but how those match up to tas_dummy() I don't know. Everything compiles, then ld says: ld: Undefined Symbol _tas any ideas here? 7.3.2 and 7.4beta3 compile just fine (I noticed that 7.4 has something more cross-platform for tas). What happened in 7.3.4 that broke it? eric
On lauantai, syys 20, 2003, at 23:37 Europe/Helsinki, Tom Lane wrote: > Is anyone on the list still running OS X 10.1, or anyway still using a > version of the OS X developer tools older than the Dec 2002 release? > It would be good to check if -no-cpp-precomp creates any problems on > any release that anyone still cares about. For the moment, I've made > src/template/darwin unconditionally use -no-cpp-precomp, but we could > probably hack it to use -traditional-cpp if there's still any interest > in Darwin compiler versions that don't recognize -no-cpp-precomp. -no-cpp-precomp replaced -traditional-cpp as the preferred syntax for turning off the precompiled header support in Mac OS X 10.1 (Darwin 5.0). Supporting Mac OS X 10.0 (Darwin 1.x) would require -traditional-cpp, but I don't think it's necessary. 10.1 was a free upgrade and it didn't remove any hardware support, so I really can't see a reason why somebody would continue to use it. mk
Eric Ridge <ebr@tcdi.com> writes:
> any ideas here? 7.3.2 and 7.4beta3 compile just fine (I noticed that
> 7.4 has something more cross-platform for tas). What happened in 7.3.4
> that broke it?
That makes no sense at all --- AFAICT there were *no* darwin or ppc
specific changes between 7.3.2 and 7.3.4. Can you double check?
regards, tom lane
On Sep 21, 2003, at 9:03 PM, Tom Lane wrote: > Eric Ridge <ebr@tcdi.com> writes: >> any ideas here? 7.3.2 and 7.4beta3 compile just fine (I noticed that >> 7.4 has something more cross-platform for tas). What happened in >> 7.3.4 >> that broke it? > > That makes no sense at all --- AFAICT there were *no* darwin or ppc > specific changes between 7.3.2 and 7.3.4. Can you double check? Looks like I misspoke. 7.3.2 does not link on 10.3 either. I don't know if this makes things better or worse. Here's the output from 7.3.2. 7.3.4 says the same thing. gcc -no-cpp-precomp -O3 -D__APPLE__ -Wall -Wmissing-prototypes -Wmissing-declarations access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lz -lreadline -ltermcap -lresolv -ldl -lm -o postgres ld: Undefined symbols: _tas make[2]: *** [postgres] Error 1 I purposely defined -O3 and -D__APPLE__ when I ./configure-d. With or w/o -D__APPLE__ things still fail. I had a whole mess of things going wrong with my 10.3 beta box (including a hardware problem), and I must have gotten things confused. Again, 7.3.2 doesn't link either. I don't think the OS X 10.3 betas are readily available (I've payed to be in Apple's developer program), so if you don't have access to 10.3 but have some idea as to what would cause this problem with tas, I'll do whatever I can to help test. eric
On Sep 21, 2003, at 9:03 PM, Tom Lane wrote: > That makes no sense at all --- AFAICT there were *no* darwin or ppc > specific changes between 7.3.2 and 7.3.4. Can you double check? Not really knowing what I'm doing, I took s_lock.c and s_lock.h from 7.4beta3, copied 'em into the 7.3.4 src tree, and recompiled. Surprisingly, everything compiled and 7.3.4 seems to be running okay (I haven't run the regression tests or tried to stress test it yet). I'm not sure this contributes to this thread in a meaningful way, but I thought it was worth mentioning. eric
Eric Ridge <ebr@tcdi.com> writes:
> I don't think the OS X 10.3 betas are readily available (I've payed to
> be in Apple's developer program), so if you don't have access to 10.3
> but have some idea as to what would cause this problem with tas, I'll
> do whatever I can to help test.
I have verified that CVS tip builds okay on 10.3 beta. I would
recommend dropping the CVS-tip versions of s_lock.h and s_lock.c
into the 7.3 source tree if you need to get 7.3 working on 10.3.
regards, tom lane
On Sep 27, 2003, at 3:43 PM, Tom Lane wrote: > Eric Ridge <ebr@tcdi.com> writes: >> I don't think the OS X 10.3 betas are readily available (I've payed to >> be in Apple's developer program), so if you don't have access to 10.3 >> but have some idea as to what would cause this problem with tas, I'll >> do whatever I can to help test. > > I have verified that CVS tip builds okay on 10.3 beta. I would > recommend dropping the CVS-tip versions of s_lock.h and s_lock.c > into the 7.3 source tree if you need to get 7.3 working on 10.3. Using s_lock.c and .h from at least 7.4 works too. Were you ever able to figure out why 7.3.4 wouldn't build? eric
"Eric B. Ridge" <ebr@tcdi.com> writes:
> Were you ever able to figure out why 7.3.4 wouldn't build?
Didn't really look, since the 7.4 inlined version of TAS is a better
solution anyway.
regards, tom lane
Eric B.Ridge wrote: > On Sep 27, 2003, at 3:43 PM, Tom Lane wrote: > >> Eric Ridge <ebr@tcdi.com> writes: >> >>> I don't think the OS X 10.3 betas are readily available (I've payed to >>> be in Apple's developer program), so if you don't have access to 10.3 >>> but have some idea as to what would cause this problem with tas, I'll >>> do whatever I can to help test. >> >> >> I have verified that CVS tip builds okay on 10.3 beta. I would >> recommend dropping the CVS-tip versions of s_lock.h and s_lock.c >> into the 7.3 source tree if you need to get 7.3 working on 10.3. > > > Using s_lock.c and .h from at least 7.4 works too. > > Were you ever able to figure out why 7.3.4 wouldn't build? > > eric > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings if you execute 'select_gcc 3.1' as root it should change your default GCC to a compiler that works.
> if you execute 'select_gcc 3.1' as root it should change your default
> GCC to a compiler that works.
That fixes the problems with -traditional-cpp v/s -no-cpp-precomp, but
it doesn't fix:
ld: Undefined symbol
_tas
eric
On Sep 27, 2003, at 3:56 PM, Tom Lane wrote: > "Eric B. Ridge" <ebr@tcdi.com> writes: >> Were you ever able to figure out why 7.3.4 wouldn't build? > > Didn't really look, since the 7.4 inlined version of TAS is a better > solution anyway. makes sense. Do you think there's a chance of getting another 7.3 point release that will compile out of the box on 10.3, when 10.3 goes gold? eric
"Eric B. Ridge" <ebr@tcdi.com> writes:
> Do you think there's a chance of getting another 7.3 point release that
> will compile out of the box on 10.3, when 10.3 goes gold?
I'm not sure whether we are planning another 7.3 release or not. I'd
like to push forward to a 7.4 release, myself. Do you have any idea
when OS X 10.3 will be released? If it's further out than next month,
we could probably plan that 7.4 will win the footrace.
regards, tom lane
On Sep 27, 2003, at 7:41 PM, Tom Lane wrote: > I'm not sure whether we are planning another 7.3 release or not. I'd > like to push forward to a 7.4 release, myself. Do you have any idea > when OS X 10.3 will be released? If it's further out than next month, > we could probably plan that 7.4 will win the footrace. By no means is this official, cuz well, I ain't in the loop, but I recently read something about mid-late November. I suspect they'll want it out by the time all the G5's are shipped... and the 2x2gig started shipping on friday... well, at least mine did. eric