Still problems with GPGME with multithread
albrecht.dress at arcor.de
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
(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...
Albrecht Dreß - Johanna-Kirchner-Straße 13 - D-53123 Bonn (Germany)
Phone (+49) 228 6199571 - mailto:albrecht.dress at arcor.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20030401/d777d45a/attachment.bin
More information about the Gnupg-devel