Need help compiling gpgme fat

Stéphane Corthésy stephane at
Sat Mar 11 17:03:34 CET 2006


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:
>> Hi,
>> I've just downloaded latest libtool (1.5.22), and replaced
>> config.guess, config.sub, install-sh and, 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.

Here's how I invoked configure:

env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 - 
arch ppc -I/usr/local/include" \
     LDFLAGS="-L/usr/local/lib -lusb -Wl,-framework -Wl,IOKit -Wl,- 
framework -Wl,CoreFoundation -Wl,-prebind" \
   ./configure --enable-m-guard --enable-noexecstack --disable- 
dependency-tracking --with-included-gettext --with-libintl-prefix=/ 
usr/local --with-libusb=/usr/local --with-readline=/usr/local

I grep'd for 'endian' in gpg source code and found several places  
where code relies on macro 'BIG_ENDIAN_HOST' (cipher/blowfish.c,  
cipher/md5.c, cipher/rmd160.c, cipher/rndunix.c, cipher/sha1.c,  
cipher/sha256.ccipher/sha512.c). Problem is that this macro is  
defined statically, after configure has been executed, whereas it  
should still be defined dynamically, depending on compiled target;  
can you change that?

> 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
> benefit?

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.



> David
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at

More information about the Gnupg-devel mailing list