Thread: Build fails on OSX using wx 2.7.0
Hi I upgraded to wxMac 2.7.0 yesterday, and I'm getting the following error now. g++ -Wall -Wno-non-virtual-dtor -I../src/include -I../src/agent/include -I../src/slony/include -L/Users/pgadmin3/Installs/PostgreSQL/8.1.3/lib-L/Users/pgadmin3/Installs/wxMac//2.7.0/lib -o pgadmin3 svnversion.o pgAdmin3.o dlgJob.o dlgSchedule.o dlgStep.o pgaJob.o pgaSchedule.o pgaStep.o base.o appbase.o sysLogger.opgConnBase.o pgSetBase.o factory.o calbox.o ctlComboBox.o ctlListView.o ctlSQLBox.o ctlSQLGrid.o ctlSQLResult.o ctlSecurityPanel.o ctlTree.o explainCanvas.o explainShape.o timespin.o xh_calb.oxh_ctlcombo.o xh_ctltree.o xh_sqlbox.o xh_timespin.o keywords.o pgConn.o pgSet.o dlgAddFavourite.o dlgAggregate.o dlgCast.o dlgCheck.o dlgColumn.o dlgConnect.o dlgConversion.o dlgDatabase.o dlgDomain.odlgEditGridOptions.o dlgFindReplace.o dlgForeignKey.o dlgFunction.o dlgGroup.o dlgHbaConfig.o dlgIndex.o dlgIndexConstraint.o dlgLanguage.o dlgMainConfig.o dlgManageFavourites.o dlgOperator.odlgPgpassConfig.o dlgProperty.o dlgRole.o dlgRule.o dlgSchema.o dlgSelectConnectio n.o dlgSequence.o dlgServer.o dlgTable.o dlgTablespace.o dlgTrigger.o dlgType.o dlgUser.o dlgView.o frmAbout.o frmBackup.ofrmConfig.o frmEditGrid.o frmExport.o frmGrantWizard.o frmHbaConfig.o frmHelp.o frmHint.o frmIndexcheck.o frmMain.o frmMainConfig.o frmMaintenance.o frmOptions.o frmPassword.o frmPgpassConfig.ofrmQuery.o frmReport.o frmRestore.o frmSplash.o frmStatus.o frmUpdate.o events.o dlgClasses.o pgAggregate.o pgCast.o pgCheck.o pgCollection.o pgColumn.o pgConstraints.o pgConversion.o pgDatabase.opgDatatype.o pgDomain.o pgForeignKey.o pgFunction.o pgGroup.o pgIndex.o pgIndexConstraint.o pgLanguage.o pgObject.o pgOperator.o pgOperatorClass.o pgRole.o pgRule.o pgSchema.o pgSequence.o pgServer.opgTable.o pgTablespace.o pgTrigger.o pgType.o pgUser.o pgView.o dlgRepCluster.o dlgRepListen.o dlgRepNode.o dlgRepPath.o dlgRepProperty.o dlgRepSequence.o dlgRepSet.o dlgRepSubscription.odlgRepTable.o slCluster.o slListen.o slNode.o slPath.o slSequence.o slSet.o slSubscript ion.o slTable.o xrcDialogs.o favourites.o md5.o misc.o pgconfig.o sysProcess.o sysSettings.o tabcomplete.o update.o utffile.o-L/Users/pgadmin3/Installs/wxMac//2.7.0/lib -framework QuickTime -framework IOKit -framework Carbon -framework Cocoa -framework System /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_aui-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_xrc-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_qa-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_html-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_adv-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_core-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_base_carbonu_xml-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_base_carbonu_net-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_base_carbonu-2.7.a-framework WebKit -lwxregexu-2.7 -lwxexpat-2.7 -lwxtiff-2.7 -lwxjpeg-2.7 -lwxpng-2.7 -lz -lpthread -liconv -L/Users/pgadmin3/Installs/wx Mac//2.7.0/lib -framework QuickTime -framework IOKit -framework Carbon -framework Cocoa -framework System /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_stc-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_macu_ogl-2.7.a /Users/pgadmin3/Installs/wxMac//2.7.0/lib/libwx_base_carbonu-2.7.a-lwxregexu-2.7 -lwxexpat-2.7 -lwxtiff-2.7 -lwxjpeg-2.7-lwxpng-2.7 -lz -lpthread -liconv -L/Users/pgadmin3/Installs/libxml2/2.6.24/lib -lxml2 -lz -lpthread -liconv -lm -L/Users/pgadmin3/Installs/libxslt/1.1.16/lib-L/Users/pgadmin3/Installs/libxml2/2.6.24/lib -lxslt -lxml2 -lz -lpthread -liconv -lm /Users/pgadmin3/Installs/PostgreSQL/8.1.3/lib/libpq.a -lssl -lcrypto ld: Undefined symbols: wxString::mb_str(wxMBConv&) const wxString::wxString(char const*, wxMBConv&, unsigned long) wxWindow::SetTitle(wxString const&) wxWindow::GetTitle() const wxFont::Init() make[2]: *** [pgadmin3] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Any ideas what might be going on? greetings, Florian Pflug
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Florian G. Pflug > Sent: 31 August 2006 09:35 > To: pgadmin-hackers > Subject: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 > > ld: Undefined symbols: > wxString::mb_str(wxMBConv&) const > wxString::wxString(char const*, wxMBConv&, unsigned long) > wxWindow::SetTitle(wxString const&) > wxWindow::GetTitle() const > wxFont::Init() > make[2]: *** [pgadmin3] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > Any ideas what might be going on? Nope that's really odd - but I found a problem on Mac late last night so am hacking on it later today when I've finished with psqlODBC. Can you wait until I'm happy with the build here before we debug yours? As an extra benefit to fixing the problem I found, we should also be building Universal binaries by the time I've finished :-) Regards, Dave.
Dave Page wrote: >>-----Original Message----- >>From: pgadmin-hackers-owner@postgresql.org >>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>Florian G. Pflug >>Sent: 31 August 2006 09:35 >>To: pgadmin-hackers >>Subject: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 >> >>ld: Undefined symbols: >>wxString::mb_str(wxMBConv&) const >>wxString::wxString(char const*, wxMBConv&, unsigned long) >>wxWindow::SetTitle(wxString const&) >>wxWindow::GetTitle() const >>wxFont::Init() >>make[2]: *** [pgadmin3] Error 1 >>make[1]: *** [all-recursive] Error 1 >>make: *** [all] Error 2 >> >>Any ideas what might be going on? > > Nope that's really odd - but I found a problem on Mac late last night so > am hacking on it later today when I've finished with psqlODBC. Can you > wait until I'm happy with the build here before we debug yours? Sure.. but note that I'm be on vacation for 3 weeks starting on sunday - so it's note rudeness if I don't answer my mails in the coming weeks ;-) Still, I debugged this further, and though I's share the results, even if you don't have time at the moment. "otool -t -v ~/Installs/wxMac/2.7.0/lib/libwx_base_carbonu-2.7.a | grep mb_str | c++filt" gives: wxString::mb_str(wxMBConv const&) const Note that additional "const" flag for the wxMBConv argument. I never knew that const-modifiers are recorded in c++ mangled names - but it seems they are, and it seems that this is causing the trouble.. I've absolutly no idea yet why c++ uses the signature including "const" when compiling wx, but the one without "const" when linking against it... My build server is still running 10.3.9, btw, with gcc 3.3 - so I guess it's this version of gcc causing the trouble.. > As an extra benefit to fixing the problem I found, we should also be > building Universal binaries by the time I've finished :-) Cool! How did you archive that? greetings, Florian Pflug
> -----Original Message----- > From: Florian G. Pflug [mailto:fgp@phlo.org] > Sent: 31 August 2006 15:14 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 > > Dave Page wrote: > >>-----Original Message----- > >>From: pgadmin-hackers-owner@postgresql.org > >>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > >>Florian G. Pflug > >>Sent: 31 August 2006 09:35 > >>To: pgadmin-hackers > >>Subject: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 > >> > >>ld: Undefined symbols: > >>wxString::mb_str(wxMBConv&) const > >>wxString::wxString(char const*, wxMBConv&, unsigned long) > >>wxWindow::SetTitle(wxString const&) > >>wxWindow::GetTitle() const > >>wxFont::Init() > >>make[2]: *** [pgadmin3] Error 1 > >>make[1]: *** [all-recursive] Error 1 > >>make: *** [all] Error 2 > >> > >>Any ideas what might be going on? > > > > Nope that's really odd - but I found a problem on Mac late > last night so > > am hacking on it later today when I've finished with > psqlODBC. Can you > > wait until I'm happy with the build here before we debug yours? > Sure.. but note that I'm be on vacation for 3 weeks starting > on sunday - > so it's note rudeness if I don't answer my mails in the > coming weeks ;-) > > Still, I debugged this further, and though I's share the results, even > if you don't have time at the moment. > > "otool -t -v > ~/Installs/wxMac/2.7.0/lib/libwx_base_carbonu-2.7.a | grep > mb_str | c++filt" > gives: > wxString::mb_str(wxMBConv const&) const > > Note that additional "const" flag for the wxMBConv argument. I never > knew that const-modifiers are recorded in c++ mangled names - but > it seems they are, and it seems that this is causing the trouble.. > > I've absolutly no idea yet why c++ uses the signature > including "const" > when compiling wx, but the one without "const" when linking > against it... > > My build server is still running 10.3.9, btw, with gcc 3.3 - > so I guess > it's this version of gcc causing the trouble.. Quite possibly. I've been successfully building on Tiger with 2.7 for a week or two. The problem I found last night is that the wx-config --rezflags option is deprecated in 2.7, thus preventing a non-debug appbundle working. Fixed that (used --rescomp instead), but then found that wx 2.7 has a --enable-universal_binary option which I've been battling with ever since. I've got pgAdmin to compile, but it won't link because my PG is not Universal. I can't for the life of me get that to build though (although there is a precompiled 8.1.3 on the net, but the configure line from that didn't work for me) Anyhoo, when I've figured out how to build PostgreSQL, we should be good to go. In the meantime though, I can't believe wx dropped support for Panther. Do the samples build and run OK? Regards, Dave.
Dave Page wrote: >>-----Original Message----- >>From: Florian G. Pflug [mailto:fgp@phlo.org] >>Sent: 31 August 2006 15:14 >>To: Dave Page >>Cc: pgadmin-hackers >>Subject: Re: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 >> >>Dave Page wrote: >> >>>>-----Original Message----- >>>>From: pgadmin-hackers-owner@postgresql.org >>>>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>>>Florian G. Pflug >>>>Sent: 31 August 2006 09:35 >>>>To: pgadmin-hackers >>>>Subject: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 >>>> >>>>ld: Undefined symbols: >>>>wxString::mb_str(wxMBConv&) const >>>>wxString::wxString(char const*, wxMBConv&, unsigned long) >>>>wxWindow::SetTitle(wxString const&) >>>>wxWindow::GetTitle() const >>>>wxFont::Init() >>>>make[2]: *** [pgadmin3] Error 1 >>>>make[1]: *** [all-recursive] Error 1 >>>>make: *** [all] Error 2 >>>> >>>>Any ideas what might be going on? >>> >>>Nope that's really odd - but I found a problem on Mac late >> >>last night so >> >>>am hacking on it later today when I've finished with >> >>psqlODBC. Can you >> >>>wait until I'm happy with the build here before we debug yours? >> >>Sure.. but note that I'm be on vacation for 3 weeks starting >>on sunday - >>so it's note rudeness if I don't answer my mails in the >>coming weeks ;-) >> >>Still, I debugged this further, and though I's share the results, even >>if you don't have time at the moment. >> >>"otool -t -v >>~/Installs/wxMac/2.7.0/lib/libwx_base_carbonu-2.7.a | grep >>mb_str | c++filt" >>gives: >>wxString::mb_str(wxMBConv const&) const >> >>Note that additional "const" flag for the wxMBConv argument. I never >>knew that const-modifiers are recorded in c++ mangled names - but >>it seems they are, and it seems that this is causing the trouble.. >> >>I've absolutly no idea yet why c++ uses the signature >>including "const" >>when compiling wx, but the one without "const" when linking >>against it... >> >>My build server is still running 10.3.9, btw, with gcc 3.3 - >>so I guess >>it's this version of gcc causing the trouble.. *Putting brown paper bag over my head*. Arg! Forget it, it was not g++ that is buggy, it turned out that the biggest bug was sitting *in front* of the computer... I've "make clean"-ed the wrong sourcetree, so my pgadmin3-trunk tree still contained some old object files built against 2.6.3... I've now cleaned my tree, and am in the process of recompiling... Sorry for the noise and confusion.. > Quite possibly. I've been successfully building on Tiger with 2.7 for a > week or two. The problem I found last night is that the wx-config > --rezflags option is deprecated in 2.7, thus preventing a non-debug > appbundle working. Fixed that (used --rescomp instead), but then found > that wx 2.7 has a --enable-universal_binary option which I've been > battling with ever since. I've got pgAdmin to compile, but it won't link > because my PG is not Universal. I can't for the life of me get that to > build though (although there is a precompiled 8.1.3 on the net, but the > configure line from that didn't work for me) Interesting.. So "universal binaries" actually contain both i386 and ppc code in one file? I've always though that universion apps just contain two different binaries for both architectures (One in "MacOS", and one in "MacOS86" or such...) > Anyhoo, when I've figured out how to build PostgreSQL, we should be good > to go. In the meantime though, I can't believe wx dropped support for > Panther. Do the samples build and run OK? Hm.. I think that complete-bundle.sh will need some work to "do the right thing" for universal binaries - Or have you already found a solution for that? greetings, Florian Pflug
> -----Original Message----- > From: Florian G. Pflug [mailto:fgp@phlo.org] > Sent: 31 August 2006 16:00 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 > > *Putting brown paper bag over my head*. Arg! Forget it, it was not > g++ that is buggy, it turned out that the biggest bug was sitting > *in front* of the computer... > > I've "make clean"-ed the wrong sourcetree, so my pgadmin3-trunk tree > still contained some old object files built against 2.6.3... > I've now cleaned my tree, and am in the process of recompiling... > > Sorry for the noise and confusion.. Bah - that would have been my normal suggestion but I figured no, Florian knows what he's doing :-p > Interesting.. So "universal binaries" actually contain both > i386 and ppc > code in one file? I've always though that universion apps just contain > two different binaries for both architectures (One in "MacOS", and one > in "MacOS86" or such...) Yeah. They can include ppc64 as well. GCC will create them just fine, or you can build them individually and combine the resulting executables and libs using the lipo tool. > > Anyhoo, when I've figured out how to build PostgreSQL, we > should be good > > to go. In the meantime though, I can't believe wx dropped > support for > > Panther. Do the samples build and run OK? > > Hm.. I think that complete-bundle.sh will need some work to "do the > right thing" for universal binaries - Or have you already found a > solution for that? I haven't fully tested it, but last time I looked it didn't appear to be much work to tweak for i386 binaries. Hopefully Universal will be similarly simple. /D
Dave Page wrote: >>-----Original Message----- >>From: Florian G. Pflug [mailto:fgp@phlo.org] >>Sent: 31 August 2006 16:00 >>To: Dave Page >>Cc: pgadmin-hackers >>Subject: Re: [pgadmin-hackers] Build fails on OSX using wx 2.7.0 >> >>*Putting brown paper bag over my head*. Arg! Forget it, it was not >>g++ that is buggy, it turned out that the biggest bug was sitting >>*in front* of the computer... >> >>I've "make clean"-ed the wrong sourcetree, so my pgadmin3-trunk tree >>still contained some old object files built against 2.6.3... >>I've now cleaned my tree, and am in the process of recompiling... >> >>Sorry for the noise and confusion.. > > Bah - that would have been my normal suggestion but I figured no, > Florian knows what he's doing :-p Yeah, well, I've thought that too... ;-) >>Interesting.. So "universal binaries" actually contain both >>i386 and ppc >>code in one file? I've always though that universion apps just contain >>two different binaries for both architectures (One in "MacOS", and one >>in "MacOS86" or such...) > > Yeah. They can include ppc64 as well. GCC will create them just fine, or > you can build them individually and combine the resulting executables > and libs using the lipo tool. Hm.. So why not compile to versions of postgres, and combine the two into one library? It's a bit hacky, but I guess it'd work for all libs that pgadmin needs, and you don't have to got fix all libs... >>Hm.. I think that complete-bundle.sh will need some work to "do the >>right thing" for universal binaries - Or have you already found a >>solution for that? > > I haven't fully tested it, but last time I looked it didn't appear to be > much work to tweak for i386 binaries. Hopefully Universal will be > similarly simple. Hm.. depends.. If the universal binary references a universal library, in the same way that a ppc binary references a ppc lib, then it should be easy... If, on the other hand, you get two references, one for the ppc-part referencing the ppc-part of the lib, and the same for the i386 parts, then fixing complete-bundle.sh will be hard greetings, Florian Pflug
On Aug 31, 2006, at 11:00, Dave Page wrote:
> Yeah. They can include ppc64 as well. GCC will create them just
> fine, or
> you can build them individually and combine the resulting executables
> and libs using the lipo tool.
That's how I build my Universal PostgreSQL binaries (and any other
configure-based project). I "./configure && make && make install" on
both a PowerPC Mac and an Intel Mac (because configure looks at the
host system to make decisions), then lipo the results together
(that's how Xcode does it, BTW). It's worked beautifully thus far,
but it does require two machines.
Here's the script I use to run lipo. I create a directory structure
like the following ("ppc" contains the binaries built on the PowerPC
machine, "i386" contains the binaries built on the x86 machine, I
duplicate one of them as "fat" so that I have the directory structure
and non-binary files in place). When I'm done, the I install the
"fat" directory on the local machine as /usr/local/pgsql and I'm set.
A full run looks something like:
$ cd postgresql-8.1.4
$ scp -r powerpc-mac:/usr/local/pgsql ppc
$ scp -r intel-mac:/usr/local/pgsql i386
$ cp -R ppc fat
$ ./run.sh
$ sudo cp -R fat /usr/local/pgsql
Directory structure
===================
postgresql-8.1.4/
to_lipo.txt
run.sh
ppc/
bin/
postmaster
...
...
i386/
bin/
postmaster
...
...
fat/
bin/
postmaster
...
...
run.sh
======
#!/bin/sh
for file in `cat to_lipo.txt`; do
echo "${file}"
lipo -create -output "fat/${file}" -arch ppc "ppc/${file}" -arch
i386 "i386/${file}"
file "fat/${file}"
done
echo "Done."
to_lipo.txt
===========
bin/clusterdb
bin/createdb
bin/createlang
bin/createuser
bin/dropdb
bin/droplang
bin/dropuser
bin/ecpg
bin/initdb
bin/pg_config
bin/pg_controldata
bin/pg_ctl
bin/pg_dump
bin/pg_dumpall
bin/pg_resetxlog
bin/pg_restore
bin/postgres
bin/psql
bin/reindexdb
bin/vacuumdb
lib/libecpg.5.1.dylib
lib/libecpg.a
lib/libecpg_compat.2.1.dylib
lib/libecpg_compat.a
lib/libpgport.a
lib/libpgtypes.2.1.dylib
lib/libpgtypes.a
lib/libpq.4.1.dylib
lib/libpq.a
lib/postgresql/ascii_and_mic.so
lib/postgresql/cyrillic_and_mic.so
lib/postgresql/euc_cn_and_mic.so
lib/postgresql/euc_jp_and_sjis.so
lib/postgresql/euc_kr_and_mic.so
lib/postgresql/euc_tw_and_big5.so
lib/postgresql/latin2_and_win1250.so
lib/postgresql/latin_and_mic.so
lib/postgresql/plpgsql.so
lib/postgresql/utf8_and_ascii.so
lib/postgresql/utf8_and_big5.so
lib/postgresql/utf8_and_cyrillic.so
lib/postgresql/utf8_and_euc_cn.so
lib/postgresql/utf8_and_euc_jp.so
lib/postgresql/utf8_and_euc_kr.so
lib/postgresql/utf8_and_euc_tw.so
lib/postgresql/utf8_and_gb18030.so
lib/postgresql/utf8_and_gbk.so
lib/postgresql/utf8_and_iso8859.so
lib/postgresql/utf8_and_iso8859_1.so
lib/postgresql/utf8_and_johab.so
lib/postgresql/utf8_and_sjis.so
lib/postgresql/utf8_and_uhc.so
lib/postgresql/utf8_and_win1250.so
lib/postgresql/utf8_and_win1252.so
lib/postgresql/utf8_and_win1256.so
lib/postgresql/utf8_and_win1258.so
lib/postgresql/utf8_and_win874.so
Thanks!
- Chris
Attachment
On 31/8/06 16:17, "Chris Campbell" <chris@bignerdranch.com> wrote:
> On Aug 31, 2006, at 11:00, Dave Page wrote:
>
>> Yeah. They can include ppc64 as well. GCC will create them just
>> fine, or
>> you can build them individually and combine the resulting executables
>> and libs using the lipo tool.
>
> That's how I build my Universal PostgreSQL binaries (and any other
> configure-based project). I "./configure && make && make install" on
> both a PowerPC Mac and an Intel Mac (because configure looks at the
> host system to make decisions), then lipo the results together
> (that's how Xcode does it, BTW). It's worked beautifully thus far,
> but it does require two machines.
Yeah, that's the downside - and until I find another generous sponsor for
the project we're stuck!!
> Here's the script I use to run lipo. I create a directory structure
> like the following ("ppc" contains the binaries built on the PowerPC
> machine, "i386" contains the binaries built on the x86 machine, I
> duplicate one of them as "fat" so that I have the directory structure
> and non-binary files in place). When I'm done, the I install the
> "fat" directory on the local machine as /usr/local/pgsql and I'm set.
>
> A full run looks something like:
>
> $ cd postgresql-8.1.4
> $ scp -r powerpc-mac:/usr/local/pgsql ppc
> $ scp -r intel-mac:/usr/local/pgsql i386
> $ cp -R ppc fat
> $ ./run.sh
> $ sudo cp -R fat /usr/local/pgsql
That's a potentially useful technique - thanks for sharing.
Regards, Dave.
On 31/8/06 19:42, "Chris Campbell" <chris@bignerdranch.com> wrote: > On Aug 31, 2006, at 14:38, Dave Page wrote: > >> Yeah, that's the downside - and until I find another generous >> sponsor for >> the project we're stuck!! > > What do you need? PostgreSQL binaries? Give me the ./configure > parameters and I'll make you some Universal binaries. --with-openssl Is all I'm using. To be honest though, whilst it would be useful to play with some Universal binaries I really need to be able to generate them myself so I can roll out new releases on short notice without having to rely on anyone else. > The only reason I use a machine with the desired architecture to > compile the binaries, rather than cross-compiling, is because of all > the configure tests that test the host machine. For the most part they shouldn't matter because the system libraries etc. should be the same on either architecture - it's not like we'd be cross compiling for Suse i386 on Redhat PPC for example. Have you ever come across anything that didn't work when cross compiling? > If we could just cache configure information (the .h file?) for OS X > rather than re-generate it from the host machine, then we'd have no > issue cross-compiling. > > So maybe if we just get someone to run ./configure (for wx? for > pgadmin?) on an Intel machine and mail in the results, then we can > save that in the repository and use it at build time? I'd certainly > be willing to run some stuff on my MacBook Pro, if I know what > commands I need to run. I don't know if you can do that - configure does far more than just building config.h; it builds all the Makefile's as well for example. Besides, even if we could get the configuration somehow, I still can't cross compile it at the moment!! Oh, incidently wx and pgAdmin seem to be working just fine - it's only PostgreSQL I'm having trouble with. I don't know if you've ever watched it build, but it appears to compile subsection by subsection, then link all the objects in a section into a SUBSYS.o file. Then, it links all the various SUBSYS.o's together to create the executable. I *think* the issue I'm having is that the first link steps (to create the SUBSYS.o's) ignore LDFLAGs, thus building them only for ppc. Regards, Dave.
On 31/8/06 21:04, "Chris Campbell" <chris@bignerdranch.com> wrote: > > Roll out releases of what? PostgreSQL? pgAdmin. I do PodtgreSQL binaries as well, but as they're for Windows I don't suppose they're relevant in this case :-) > Yeah, all the test-and-set stuff. PostgreSQL uses different test-and- > set techniques on different architectures, and (afaik) actually > executes code at configure-time to test such things (some of the code > is assembly, I think?). Oh right - I thought that was hardcoded for each architecture. Didn't realise there was a configure time test. > I wouldn't trust a cross-compiled PostgreSQL binary as much as I > would a built-on-native binary. Which is why I build natively on each > platform and lipo them together for my clients that distribute > PostgreSQL in their products. No - which thinking about it is not actually an issue for me as I only actually need libpq. As that's capable of being built on it's own (and isn't build form multiple subsystems from what I can remember) I can probably just get away with that. Cheers, Dave.
Dave Page wrote: > > > On 31/8/06 16:17, "Chris Campbell" <chris@bignerdranch.com> wrote: > >> On Aug 31, 2006, at 11:00, Dave Page wrote: >> >>> Yeah. They can include ppc64 as well. GCC will create them just >>> fine, or >>> you can build them individually and combine the resulting executables >>> and libs using the lipo tool. >> That's how I build my Universal PostgreSQL binaries (and any other >> configure-based project). I "./configure && make && make install" on >> both a PowerPC Mac and an Intel Mac (because configure looks at the >> host system to make decisions), then lipo the results together >> (that's how Xcode does it, BTW). It's worked beautifully thus far, >> but it does require two machines. > > Yeah, that's the downside - and until I find another generous sponsor for > the project we're stuck!! I just played around a bit on my laptop running 10.4, and was able to compile a universal version of libpq, pg_dum and pg_config. What I did was: 1) export CFLAGS="-arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk/" 2) export LDFLAGS="-arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk/" 3) ./configure 4) cd src/interfaces/libpq; make 5) cd src/backend; make ../../src/include/parser/parse.h 6) src/bin/pg_config; make 7) src/bin/pg_dump; make The only problem I can see is that ld isn't able to generate universal binaries - it can read them, but always strips all but one arch when generating output... The apple gcc, however supports multiple archs just fine, and even knows that it has to call ld repeatedly, and then merge the resuting files... So, to build a complete postgres distribution, I believe one would have to somehow tell configure to use gcc instead ld (if it doesn't already do that). But for building pgadmin3, the parts I built above are sufficient - in fact, those are exactly the parts of postgres that my buildaemon-postgres-update script builds ;-) (Don't ask me why step (5) is necessary... It was quite a long time ago that I wrote this script... ;-) ). greetings, Florian Pflug
Florian G. Pflug wrote: > Dave Page wrote: >> >> >> On 31/8/06 16:17, "Chris Campbell" <chris@bignerdranch.com> wrote: >> >>> On Aug 31, 2006, at 11:00, Dave Page wrote: >>> >>>> Yeah. They can include ppc64 as well. GCC will create them just >>>> fine, or >>>> you can build them individually and combine the resulting executables >>>> and libs using the lipo tool. >>> That's how I build my Universal PostgreSQL binaries (and any other >>> configure-based project). I "./configure && make && make install" on >>> both a PowerPC Mac and an Intel Mac (because configure looks at the >>> host system to make decisions), then lipo the results together >>> (that's how Xcode does it, BTW). It's worked beautifully thus far, >>> but it does require two machines. >> >> Yeah, that's the downside - and until I find another generous sponsor for >> the project we're stuck!! > > I just played around a bit on my laptop running 10.4, and was able to > compile a universal version of libpq, pg_dum and pg_config. > What I did was: > > 1) export CFLAGS="-arch i386 -arch ppc -isysroot > /Developer/SDKs/MacOSX10.4u.sdk/" > 2) export LDFLAGS="-arch i386 -arch ppc -isysroot > /Developer/SDKs/MacOSX10.4u.sdk/" > 3) ./configure > 4) cd src/interfaces/libpq; make > 5) cd src/backend; make ../../src/include/parser/parse.h > 6) src/bin/pg_config; make > 7) src/bin/pg_dump; make > > The only problem I can see is that ld isn't able to generate universal > binaries - it > can read them, but always strips all but one arch when generating output... > The apple gcc, however supports multiple archs just fine, and even knows > that it > has to call ld repeatedly, and then merge the resuting files... > So, to build a complete postgres distribution, I believe one would have > to somehow tell > configure to use gcc instead ld (if it doesn't already do that). > > But for building pgadmin3, the parts I built above are sufficient - in > fact, those > are exactly the parts of postgres that my buildaemon-postgres-update > script builds ;-) > (Don't ask me why step (5) is necessary... It was quite a long time ago > that I wrote > this script... ;-) ). Clicked send a bit too fast - what I forgot to mention was that I'm use XCode 2.4 on my laptop greetings, Florian Pflug
On 1/9/06 02:49, "Florian G. Pflug" <fgp@phlo.org> wrote: > Florian G. Pflug wrote: >> Dave Page wrote: >>> >> >> I just played around a bit on my laptop running 10.4, and was able to >> compile a universal version of libpq, pg_dum and pg_config. >> What I did was: >> >> 1) export CFLAGS="-arch i386 -arch ppc -isysroot >> /Developer/SDKs/MacOSX10.4u.sdk/" >> 2) export LDFLAGS="-arch i386 -arch ppc -isysroot >> /Developer/SDKs/MacOSX10.4u.sdk/" >> 3) ./configure >> 4) cd src/interfaces/libpq; make >> 5) cd src/backend; make ../../src/include/parser/parse.h >> 6) src/bin/pg_config; make >> 7) src/bin/pg_dump; make >> >> The only problem I can see is that ld isn't able to generate universal >> binaries - it >> can read them, but always strips all but one arch when generating output... >> The apple gcc, however supports multiple archs just fine, and even knows >> that it >> has to call ld repeatedly, and then merge the resuting files... >> So, to build a complete postgres distribution, I believe one would have >> to somehow tell >> configure to use gcc instead ld (if it doesn't already do that). >> >> But for building pgadmin3, the parts I built above are sufficient - in >> fact, those >> are exactly the parts of postgres that my buildaemon-postgres-update >> script builds ;-) >> (Don't ask me why step (5) is necessary... It was quite a long time ago >> that I wrote >> this script... ;-) ). Yes, that sounds like roughly the procedure I working toward in between other tasks. > Clicked send a bit too fast - what I forgot to mention was that I'm use XCode > 2.4 on my laptop Oh, didn't know it was out. I'll have to upgrade... Cheers, Dave.