Need help compiling gpgme fat

[Stéphane Corthésy]

Hi,

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:
>> Hi,
>>
>> 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 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 */
>   #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

#include <machine/endian.h>
#ifdef BIG_ENDIAN && LITTLE_ENDIAN
   #if BYTE_ORDER==BIG_ENDIAN
     #define BIG_ENDIAN_HOST 1
     #undef LITTLE_ENDIAN_HOST
   #elif BYTE_ORDER==LITTLE_ENDIAN
     #undef BIG_ENDIAN_HOST
     #define LITTLE_ENDIAN_HOST 1
   #else
     #error Unsupported endianness
   #endif
#else
   #error Endianness macros are undefined!
#endif


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/ 
lib/libreadline.a" \
   ./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
>
> part?


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  
>>> 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.
>
> Fair enough.
>
> David


Thanks for your help,

Stéphane