Need help compiling gpgme fat
stephane at sente.ch
Sat Mar 11 20:07:58 CET 2006
On Mar 11, 2006, at 18:39 , David Shaw wrote:
> 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
>>> 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
>>> 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 */
> #undef BIG_ENDIAN_HOST
> and this:
> /* Defined if the host has little endian byte ordering */
> #undef LITTLE_ENDIAN_HOST
> Then add this:
> #define BIG_ENDIAN_HOST __BIG_ENDIAN__
> #define LITTLE_ENDIAN_HOST __LITTLE_ENDIAN__
I finally solved it like that: I modified config.h and added
#ifdef BIG_ENDIAN && LITTLE_ENDIAN
#define BIG_ENDIAN_HOST 1
#define LITTLE_ENDIAN_HOST 1
#error Unsupported endianness
#error Endianness macros are undefined!
Maybe it's portable for other platforms?
> Then configure with:
> ./configure CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch
> ppc -arch i386" --disable-dependency-tracking --disable-asm
I don't need to disable asm, do I? I didn't and it worked. Actually,
I had to use that config line (the one I posted before wasn't
correct; system's libreadline is too old, and I need to pass full
path to new libreadline; I also need libtermcap):
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 -ltermcap -Wl,/usr/local/
./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
BTW, is it better or not to enable memory-guard and noexecstack? Why
aren't they enabled by default?
> Let me know if this works for you.
It probably does, as it solves the endiannes problem, and doesn't use
any special lib.
I'll see that tomorrow.
> If you are doing the build on
> Intel, can you also try this with skipping the
> -isysroot /Developer/SDKs/MacOSX10.4u.sdk
I don't have an Intel; anyway, I think you're right, in that case we
don't need the isysroot, because on Intel libs are fat, IIRC.
> 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
>>> to maintain two different products generated from the same source
>>> code, with twice as much space in warehouses, etc). For free
>>> 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.
> Fair enough.
Thanks for your help,
More information about the Gnupg-devel