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)?
Stéphane
On Mar 5, 2006, at 18:18 , Stéphane Corthésy wrote:
> Hi,
>> On Mar 5, 2006, at 17:37 , Marcus Brinkmann wrote:
>>> At Sat, 4 Mar 2006 19:04:08 +0100,
>> Stéphane Corthésy wrote:
>>> I'm trying to compile gpgme 1.1.2 on MacOSX, as a fat static
>>> library.
>>>> Can you enlighten me? What's a "fat" library?
>>> A library containing code for multiple processor architectures. In
> my case, OSX for intel and ppc.
>>>>> I could compile gpg-error 1.2 as a fat library; I had some troubles,
>>> but could solve them: that new version needs now libintl (version
>>> 1.0
>>> didn't), and the configure script doesn't say anything when it
>>> doesn't find it; user notices it only when compiling library.
>>>> Well, we need to call bindtextdomain. It should be easy to add a
>> configure check for that, can you submit a patch? (Alternatively, I
>> can send you a patch for testing).
>>> Sorry, I know absolutely nothing about automake, autoconf and these
> tools.
> Anyway, I have libintl installed on my machine, so it's no longer a
> problem for me.
>>>>> I applied the same patch to gpgme's libtool, but it seems it is not
>>> enough, as I think gpgme is not built/linked the same way as gpg-
>>> error:
>>>> gpgme links a shared library from some files and a static library
>> (which it built itself). This requires special support on some
>> platforms, and in fact may not be available on all platforms.
>> libtool
>> encapsulates this properly. You may need to extend libtool to
>> support
>> "fat" libraries (whatever they are :)
>>> Hmm, well, too hard for me. I tried tweaking resulting libtool, and
> went further in the build, until stumbling on the fact that 'ar'
> doesn't like adding files with multiple architectures on an
> existing archive; creating a single archive for multiple
> architectures works though. Maybe a limitation of 'ar'.
>>>> The alternative would be to recompile every file for each of the
>> thread packages. This is certainly possible, however, there are
>> other
>> packages where this trick is used. It's quite convenient.
>>>> Thanks,
>> Marcus
>>> That would do the trick, if libtool was invoked only once for all
> files, like it is the case for libgpg-error. Problem is that I
> don't know where I should patch makefiles.
> I'll try to compile gpgme twice, one for each architecture, and
> then 'lipo' them. And I'll post the question about GNU libtool on
> macosx mailing lists.
>> Cheers,
>> Stéphane
>>> _______________________________________________
> Gnupg-devel mailing list
>Gnupg-devel at gnupg.org>http://lists.gnupg.org/mailman/listinfo/gnupg-devel