gpgme 0.3.8
Stéphane Corthésy
stephane@sente.ch
Fri Jul 26 16:18:01 2002
--Apple-Mail-1--6191275
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
Hi,
On Thursday, July 25, 2002, at 08:01 PM, Marcus Brinkmann wrote:
On Sun, Jul 14, 2002 at 11:40:47AM +0200, St=E9phane Corth=E9sy 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=20
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=20
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=20
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()=20
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=20
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=20
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=E9phane Corth=E9sy 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=20
your
configuration? I will have to work on this, we can probably make the=20
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=20=
month or so, as we will use gcc 3.
Thanks for having corrected all this :-)
St=E9phane
P.-S.
Due to restrictions imposed by GPL, I will abandon helping supporting=20
GPGME on MacOS X, finding no longer reasons to do it: my main goal was=20=
to use GPGME in GPGMail, which is a (hacked) plug-in for Apple's Mail;=20=
Mail is not GPL, its sources are not available, it's delivered with=20
MacOS X; GPGMail uses a BSD-like license scheme. Till now I was=20
interfacing GPGMail to gpg through pipes, I wasn't aware that I was=20
violating the GPL (note that other software do the same, like Evolution;=20=
even rewriting their own GPGME-like clone breaks GPL, if I understand it=20=
correctly). I thought that using gpg/gpgme in another process than=20
GPGMail was not breaking GPL, and was about to use a client-server=20
pattern to workaround the process limit when using GPGME. I realize now=20=
that's it's useless, and that no un-GPL'ed application on MacOS X will=20=
ever have right to use gpg :-(
I find the GPL particularly uncomfortable, but won't discuss on it -=20
there were already many messages on that subject. In my case I was just=20=
hacking around, spending a lot of time on something that is totally=20
free, and have to stop now.
--Apple-Mail-1--6191275
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1
Hi,
On Thursday, July 25, 2002, at 08:01 PM, Marcus Brinkmann wrote:
<color><param>0000,0000,DEDE</param>On Sun, Jul 14, 2002 at 11:40:47AM
+0200, St=E9phane Corth=E9sy wrote:
</color><color><param>0000,6363,1212</param>I tried to compile gpgme
0.3.8 on MacOS X, but I failed to compile it=20
out-of-the-box :-(
</color><color><param>0000,0000,DEDE</param>
I hope it works better now ;)
</color><color><param>0000,0000,0000</param>
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.
</color><color><param>0000,6363,1212</param>Basically, there are no
vasprintf() and asprintf() functions on MacOS X;=20
I tried using the replacement you provide (it was not part of 0.3.8=20
distro, but I found it in the repository), but it doesn't work: even
the=20
test suite on vasprintf() fails:
</color><color><param>0000,0000,DEDE</param>
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]
</color><color><param>0000,0000,0000</param>
It still doesn't work: memcpy() is probably the problem. va_copy()
doesn't exist on MacOS X.
</color><color><param>0000,0000,DEDE</param>
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?
</color><color><param>0000,0000,0000</param>
Unable to test it until gpgme 0.3.9 goes out.
</color><color><param>0000,0000,DEDE</param>
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 :)
</color><color><param>0000,6363,1212</param>(Note that the prototype
of vasprintf() in gpgme/util.h is wrong;
</color><color><param>0000,0000,DEDE</param>
Indeed.
</color><color><param>0000,6363,1212</param>There are also #include
problems in gpgme/ath-pth.c and ath-pthread.c:=20
instead of #including <<malloc.h> (which doesn't exist on MacOS X; we=20
have <<sys/malloc.h>), I need to #include <<stdlib.h>.
</color><color><param>0000,0000,DEDE</param>
Fixed, thanks.
</color><color><param>0000,0000,0000</param>
In fact, on MacOS X we use only ath-pthread.c, as we have pthread
support.
</color><color><param>0000,0000,DEDE</param>
</color><color><param>0000,6363,1212</param>During compilation there
were also some #warnings which should be=20
corrected:
</color><color><param>0000,0000,DEDE</param>
All of them fixed, thanks.
On Thu, Jul 25, 2002 at 04:12:41PM +0200, St=E9phane Corth=E9sy wrote:
</color><color><param>0000,6363,1212</param>Here's a new version of
the patch we use on MacOS X.
</color><color><param>0000,0000,DEDE</param>
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.
</color>
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=E9phane
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.
--Apple-Mail-1--6191275--