Need help compiling gpgme fat
dshaw at jabberwocky.com
Sat Mar 11 18:39:47 CET 2006
On Sat, Mar 11, 2006 at 05:03:34PM +0100, Stéphane Corthésy wrote:
> On Mar 5, 2006, at 21:49 , David Shaw wrote:
> >On Sun, Mar 05, 2006 at 06:49:20PM +0100, Stéphane Corthésy wrote:
> >>I've just downloaded latest libtool (1.5.22), and replaced
> >>config.guess, config.sub, install-sh and ltmain.sh, applied my
> >>previous patch on generated libtool, and now it works :-) I can now
> >>build libgpgme for both ppc and intel in one pass/one lib.
> >>(maybe my patch is not even needed, I haven't tried yet without it)
> >>When will you upgrade your libtool (as well as gpg's, as I guess
> >>there is the same problem when trying to compile gpg as fat binary)?
> >No, GPG doesn't use libtool. In theory, compiling a fat GPG binary is
> >pretty simple. The main difficulty is getting the endian stuff for
> >the ciphers right (ppc being big, and intel being little).
> >I'm able to build a fat binary that passes the selftest on my ppc OSX
> >box. If you (or anyone here) has an intel OSX box and is willing to
> >test as well, let me know. In theory, it should be as simple as a
> >change to the configure script, but there is no way to tell without
> >trying it.
> OK. I've just tried it, and it doesn't work: endianness is wrongly
> determined by 'configure' when passing '-arch i386 -arch ppc' (or in
> reverse order) to the CFLAGS in order to build a fat version: when
> compiling on my ppc, endianness is determined as little, whereas it
> is big! (If I don't compile it fat, endianness is correct). So, I
> wonder how your binary could even work on your ppc, if gpg relies on
> the 'configure' endianness info - tests shouldn't pass.
I'm not running the stock configure stuff ;)
Here's how to do it - edit config.h.in (not config.h) and remove this:
/* Defined if the host has big endian byte ordering */
/* Defined if the host has little endian byte ordering */
Then add this:
#define BIG_ENDIAN_HOST __BIG_ENDIAN__
#define LITTLE_ENDIAN_HOST __LITTLE_ENDIAN__
Then configure with:
./configure CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" --disable-dependency-tracking --disable-asm
Let me know if this works for you. If you are doing the build on
Intel, can you also try this with skipping the
Let me know if this works for you (as I said, it builds correctly on
ppc and passes the selftest, but I can't test Intel). If it works ok
for Intel, I'll include the patch as part of 1.4.3.
> >I have to admit, though, I'm not sure what the benefit of a fat GPG
> >is. The idea behind fat binaries is a good one (companies don't need
> >to maintain two different products generated from the same source
> >code, with twice as much space in warehouses, etc). For free software
> >like GPG that is "shipped" as source, I'm curious where is the
> MacGPG Group provides a binary of gpg for MacOSX; unlike most Linux
> users, Mac users are not used to build the binaries of everything
> they want to use; most of them know nothing about command line and
> code compilation; I agree that building gpg is not difficult, but
> it's still too frightening for most users, that's why MacGPG provides
> the fat binary: just download the package, double-click it, and it
> will install everything for you.
More information about the Gnupg-devel