stephane at sente.ch
Fri Jul 26 17:18:01 CEST 2002
On Thursday, July 25, 2002, at 08:01 PM, Marcus Brinkmann wrote:
On Sun, Jul 14, 2002 at 11:40:47AM +0200, Stéphane Corthésy wrote:
I tried to compile gpgme 0.3.8 on MacOS X, but I failed to compile it
I hope it works better now ;)
I can't test it now, because I can't generate the automake files on
MacOS X; I need to wait for gpgme 0.3.9.
Basically, there are no vasprintf() and asprintf() functions on MacOS X;
I tried using the replacement you provide (it was not part of 0.3.8
distro, but I found it in the repository), but it doesn't work: even the
test suite on vasprintf() fails:
I fixed and updated the replacement, can you please try the new
that doesn't work either, it might be because of using memcpy instead
va_copy. If that is the case, we have a problem ;) [well, nothing
but it would be nice to see it working now, as this is the version of
vasprintf used in libiberty, too]
It still doesn't work: memcpy() is probably the problem. va_copy()
doesn't exist on MacOS X.
I added a fix to the makefile that should make vasprintf part of the
distribution, and add it to the objects linked into the library, too, can
you please verify this?
Unable to test it until gpgme 0.3.9 goes out.
BTW, it seems to me we shouldn't add vasprintf like this, because it
exported to applications, and that might collide with a private vasprintf
that is not compatible. Well, hopefully nobody does that :)
(Note that the prototype of vasprintf() in gpgme/util.h is wrong;
There are also #include problems in gpgme/ath-pth.c and ath-pthread.c:
instead of #including <malloc.h> (which doesn't exist on MacOS X; we
have <sys/malloc.h>), I need to #include <stdlib.h>.
In fact, on MacOS X we use only ath-pthread.c, as we have pthread
During compilation there were also some #warnings which should be
All of them fixed, thanks.
On Thu, Jul 25, 2002 at 04:12:41PM +0200, Stéphane Corthésy wrote:
Here's a new version of the patch we use on MacOS X.
It seems you have problems with #pragma weak? Is it not supported in
configuration? I will have to work on this, we can probably make the
support working on other platforms but GNU systems, but it won't be as
That pragma is currently unknown for our compiler; it will change in one
month or so, as we will use gcc 3.
Thanks for having corrected all this :-)
Due to restrictions imposed by GPL, I will abandon helping supporting
GPGME on MacOS X, finding no longer reasons to do it: my main goal was
to use GPGME in GPGMail, which is a (hacked) plug-in for Apple's Mail;
Mail is not GPL, its sources are not available, it's delivered with
MacOS X; GPGMail uses a BSD-like license scheme. Till now I was
interfacing GPGMail to gpg through pipes, I wasn't aware that I was
violating the GPL (note that other software do the same, like Evolution;
even rewriting their own GPGME-like clone breaks GPL, if I understand it
correctly). I thought that using gpg/gpgme in another process than
GPGMail was not breaking GPL, and was about to use a client-server
pattern to workaround the process limit when using GPGME. I realize now
that's it's useless, and that no un-GPL'ed application on MacOS X will
ever have right to use gpg :-(
I find the GPL particularly uncomfortable, but won't discuss on it -
there were already many messages on that subject. In my case I was just
hacking around, spending a lot of time on something that is totally
free, and have to stop now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 4701 bytes
Desc: not available
Url : /pipermail/attachments/20020726/3e9605ee/attachment.bin
More information about the Gnupg-devel