Still problems with GPGME with multithread

Albrecht Dreß albrecht.dress at
Tue Apr 1 21:55:02 CEST 2003

Am 01.04.03 01:04 schrieb(en) Laurent Cheylus:
> I test to modify the link order ('-lpthread' before '-lgpgme' at
> compilation) as described in a precedent thread (Albrecht's solution).
> But for me, it doesn't solve the issue :-(

Unfortunately, the situation seems to be more complicated, so please let 
me add a few points.

(1) I patched the configure file so that libgpgme comes after libpthread 
in the list of libs. This list, however, is fed into libtool which has its 
own ideas of a proper linking order, and reversed it. I must admit that I 
don't like libtool, but it's a fact that many tools rely on it. I have no 
idea if libtool has a switch in the la file saying "if libfoo is present, 
it must come before me", but if so, libgpgme should support it correctly 
(aka bug...).

(2) Currently there is no way for the programmer to see if the mt safe 
initialisation was successful or not. It would be *really* helpful if I 
could get some information about that (e.g. if gpgme_check_version() 
returned 0.3.15-MT in this case).

(3) As the programmers will usually know if a program uses mt or not, why 
don't you implement a routine like gpgme_init_threading() which is just a 
no-op if the library figured out itself that it's needed?

(4) The proper linking order itself seems to be only part of the game, as 
Pawel Salek saw libpthread coming *after* libgpgme on RH8 and RH9beta, but 
it *does* work. Maybe a glibc problem?

Just my € 0.01...

Cheers, Albrecht.

  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20030401/d777d45a/attachment.bin

More information about the Gnupg-devel mailing list