Обсуждение: MacOS X 10.5.1 and compiling for multiple Architectures
Hello all, I am trying to build PG 8.3Beta4 for MacOS Leopard. It works fine when using the default i386 architecture. However, this is not an option as Apple, in their wisdom, have chosen to build Apache as a 64-bit application and their PHP 5.2.4 module without PG support as a Intel 32, Intel 64, PPC 32 and PPC 64 type module. For those that don't know: Under MacOS, it is possible to build executables that will run native on multiple architectures, all contained in a single file - kind of weird, and pretty bloated. Today, I managed to build PG as either i386 or x86_64 binaries, but not both. The 'make' process crashed at this point: gcc -no-cpp-precomp -arch x86_64 -arch i386 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels - fno-strict-aliasing -I../../../../src/include -c -o heaptuple.o heaptuple.c heaptuple.c: In function 'heap_fill_tuple': heaptuple.c:250: error: duplicate case value heaptuple.c:250: error: previously used here heaptuple.c: In function 'DataFill': heaptuple.c:383: error: duplicate case value heaptuple.c:383: error: previously used here lipo: can't figure out the architecture type of: /var/tmp//cc4ObL54.out make[4]: *** [heaptuple.o] Error 1 make[3]: *** [common-recursive] Error 2 make[2]: *** [access-recursive] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 When looking at the source line, I see: store_att_byval(data, values[i], att[i]->attlen); I have checked this using 8.2.5 as well, with the same results (except that the errors are on different line numbers, but in the same file, using the same function and arguments). Any help is appreciated. best regards, chris -- chris ruprecht network grunt and bit pusher extraordinaíre
Вложения
Chris Ruprecht <chris@ruprecht.org> writes:
> I am trying to build PG 8.3Beta4 for MacOS Leopard.
> It works fine when using the default i386 architecture. However, this
> is not an option as Apple, in their wisdom, have chosen to build
> Apache as a 64-bit application and their PHP 5.2.4 module without PG
> support as a Intel 32, Intel 64, PPC 32 and PPC 64 type module. For
> those that don't know: Under MacOS, it is possible to build
> executables that will run native on multiple architectures, all
> contained in a single file - kind of weird, and pretty bloated.
You're not going to have a lot of luck building PG for those four
architectures from a single build run --- you really need a different
pg_config.h for each case. The specific failure you're seeing seems
to stem from SIZEOF_DATUM not agreeing with sizeof(Datum), but you
can bet your bottom dollar that that's just the tip of the iceberg.
I'd be somewhat interested to see a build approach that supports this,
but I don't want to spend any of my own time on it. I have a vague
suspicion that Apple probably built PHP four separate times and then
melded the executables after the fact.
regards, tom lane
Chris Ruprecht wrote: > Hello all, > > I am trying to build PG 8.3Beta4 for MacOS Leopard. > It works fine when using the default i386 architecture. However, this is > not an option as Apple, in their wisdom, have chosen to build Apache as > a 64-bit application and their PHP 5.2.4 module without PG support as a > Intel 32, Intel 64, PPC 32 and PPC 64 type module. For those that don't > know: Under MacOS, it is possible to build executables that will run > native on multiple architectures, all contained in a single file - kind > of weird, and pretty bloated. > It was noted a while back that pg had issues with 64 bit on osx - unsure if it was resolved. http://archives.postgresql.org/pgsql-general/2007-08/msg01410.php I do recall some time back there was discussion about getting pg to be built as a fat binary on osx, but it doesn't seem to have made it into the source. one place that may help you for now is http://www.entropy.ch/blog/Software/2006/02/04/PostgreSQL-Universal-Binary-Build-Tips.html and http://www.entropy.ch/phpbb2/viewtopic.php?p=9579#9579 -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz
Hey Tom, Shane, actually, PHP w/out the PG stuff builds just fine with x86_64 and i386 specified at the same time. I didn't bother with the PPC architectures, since I don't have a Leopard capable PPC box any more. My old PowerBook G3/500 point blank refuses to run anything higher than 10.4.11 :). When I tried the build, including the PG libs for both architectures, I got error messages for missing symbols only for the i386 architecture (since I only built the PG libs for 64-bit). Everything else seemed to be present. I'm good to run with the x86_64 only binary since my Apache is built using that architecture. I'm also not to worried about any bugs in the 64-bit OS X code, this is for development only, no live data, ever. If it crashes or mangles up my data, so be it, backups must be good for something, right? Would have been nice though, to go and give the completely built libphp5.so module to somebody and say 'here, run it' regardless of what his hardware architecture supports. best regards, chris -- chris ruprecht network grunt and bit pusher extraordinaíre On Jan 3, 2008, at 00:41, Tom Lane wrote: > Chris Ruprecht <chris@ruprecht.org> writes: >> I am trying to build PG 8.3Beta4 for MacOS Leopard. >> It works fine when using the default i386 architecture. However, this >> is not an option as Apple, in their wisdom, have chosen to build >> Apache as a 64-bit application and their PHP 5.2.4 module without PG >> support as a Intel 32, Intel 64, PPC 32 and PPC 64 type module. For >> those that don't know: Under MacOS, it is possible to build >> executables that will run native on multiple architectures, all >> contained in a single file - kind of weird, and pretty bloated. > > You're not going to have a lot of luck building PG for those four > architectures from a single build run --- you really need a different > pg_config.h for each case. The specific failure you're seeing seems > to stem from SIZEOF_DATUM not agreeing with sizeof(Datum), but you > can bet your bottom dollar that that's just the tip of the iceberg. > > I'd be somewhat interested to see a build approach that supports this, > but I don't want to spend any of my own time on it. I have a vague > suspicion that Apple probably built PHP four separate times and then > melded the executables after the fact. > > regards, tom lane
Вложения
Chris Ruprecht wrote: > Hey Tom, Shane, > I'm good to run with the x86_64 only binary since my Apache is built > using that architecture. That's not a real reason to run pg in 64 bit. Although you would need php and libpq to be the same architecture as apache (the running architect if multiple available) - the postgresql server can be 32 bit. If apache is only 64 bit then you will need a 64 bit libpq. Apache calls functions in the php module which then calls functions in the libpq - they must all have matching architectures available to do this which is why apple supplies fat binary libs with osx. From there to postgresql is a network connection (or local socket) so each program is just sending data to the other - they don't need to be the same architecture any more than you need a 64 bit sparc browser to connect to a 64 bit sparc web server. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz
Hi Shane, Sure, I'm aware of that. I meant, that I have the PHP module running as 64-bit (since the Apple- provided Apache is 64-bit) but without the other architectures built- in. I know that I can re-build PG to be only 32 bit, but since we're slowly moving into a 64-bit world anyway, there is no real need to do that, except if there are major issues with PG 64-bit under OS X. So far, it's still up and running. best regards, chris -- chris ruprecht network grunt and bit pusher extraordinaíre On Jan 3, 2008, at 14:09, Shane Ambler wrote: > Chris Ruprecht wrote: >> Hey Tom, Shane, > >> I'm good to run with the x86_64 only binary since my Apache is >> built using that architecture. > > That's not a real reason to run pg in 64 bit. > > Although you would need php and libpq to be the same architecture as > apache (the running architect if multiple available) - the > postgresql server can be 32 bit. If apache is only 64 bit then you > will need a 64 bit libpq. > > > Apache calls functions in the php module which then calls functions > in the libpq - they must all have matching architectures available > to do this which is why apple supplies fat binary libs with osx. > > > From there to postgresql is a network connection (or local socket) > so each program is just sending data to the other - they don't need > to be the same architecture any more than you need a 64 bit sparc > browser to connect to a 64 bit sparc web server. > > > > -- > > Shane Ambler > pgSQL (at) Sheeky (dot) Biz > > Get Sheeky @ http://Sheeky.Biz > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly