gpgme 0.3.8

[Stéphane Corthésy]

Hi,

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
out-of-the-box :-(

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 
version?  If
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 
critical,
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 
will be
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;

Indeed.

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>.

Fixed, thanks.


In fact, on MacOS X we use only ath-pthread.c, as we have pthread 
support.


During compilation there were also some #warnings which should be
corrected:

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 
your
configuration?  I will have to work on this, we can probably make the 
thread
support working on other platforms but GNU systems, but it won't be as
convenient.


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 :-)

Stéphane


P.-S.
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
Type: text/enriched
Size: 4701 bytes
Desc: not available
Url : /pipermail/attachments/20020726/3e9605ee/attachment.bin