Re: Universal libpq.a ?
От | Larry Rosenman |
---|---|
Тема | Re: Universal libpq.a ? |
Дата | |
Msg-id | 20080205090621.O85310@thebighonker.lerctr.org обсуждение исходный текст |
Ответ на | Re: Universal libpq.a ? ("Dave Page" <dpage@postgresql.org>) |
Ответы |
Re: Universal libpq.a ?
Re: Universal libpq.a ? |
Список | pgsql-general |
On Tue, 5 Feb 2008, Dave Page wrote: > On Feb 5, 2008 1:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> # Fixup the makefiles >>> echo "Post-processing Makefiles for Universal Binary build" >>> find . -name Makefile -print -exec perl -p -i.backup -e 's/\Q$(LD) >>> $(LDREL) $(LDOUT)\E (\S+) (.+)/\$(LD) -arch ppc \$(LDREL) \$(LDOUT) >>> $1.ppc $2; \$(LD) -arch i386 \$(LDREL) \$(LDOUT) $1.i386 $2; lipo >>> -create -output $1 $1.ppc $1.i386/' {} \; || _die "Failed to >>> post-process the Postgres Makefiles for Universal build" >> >> I thought I'd read that you could solve this problem by using the gcc >> frontend to invoke loading, ie something involving making $(LD) call gcc >> with some options. I'd be willing to tweak the LDxxx macros a bit if >> needed to enable a solution like that, but changing the Makefiles at >> build time is clearly right out ... > > My make-fu is not strong enough for that - which is why thats the bit > I nicked from the entropy.ch scripts! > > Another option which may be doable for someone with more knowledge of > make would be to build binaries for all architectures seperately (you > can build i386, ppc, x86_64 and ppc64), and then use lipo to glue them > together. I did essentially that, outside of make, for ppc/i386 doing 2 separate builds and then using lipo to join each file in bin and lib. LER > > /D > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
В списке pgsql-general по дате отправления: