Need help compiling gpgme fat

[David Shaw]

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__

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

  -isysroot /Developer/SDKs/MacOSX10.4u.sdk

part?

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