Still problems with GPGME with multithread

[Marcus Brinkmann]

On Tue, Apr 01, 2003 at 07:59:53PM +0200, Albrecht Dreß wrote:
> (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...).

Don't blame libtool, we are not feeding it all the information it needs to
figure out what it should do.  This is indeed a problem, thanks for figuring
that out.  I think that people should be able to use libtool, so there are
two ways to go from here, enhance libtool or fix it in gpgme.

I am not sure how you use libtool, but it seems you are using -lgpgme.la. 
For a workaround, try without that and link to -lgpgme direcly, or even
"-lpthread -lgpgme", so it doesn't consider the la script and maybe that
helps to avoid the reordering.  As gpgme itself does not depend on other
libraries yet this is harmless.  Mmmh.  It seems to me that you should use
gpgme-config anyway, but I am not sure if the effect shouldn't be equivalent
(there is some overlap in the functionality of gpgme-config and .la
scripts).  Except that gpgme-config doesn't point you to .la but to the
library directly.

I will consider the alternatives (fixing libtool or gpgme).

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

The reason is that it's supposed to be completely automatic and always work
correct.  I don't believe in interfaces that are only there to find out if
something that always should work really did work.  If it should always work
and doesn't, then it is a bug and should be fixed.  Don't compromise on bugs!

> (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?

I don't really want to link at run time, there is no need for that here.

> (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?

Well, nobody really has investigated so far why it does hang sometimes if
the linking order is incorrect, so I can't really say anything about that.
It's certainly an interesting, but distinct issue.  Feel free to dig into
that hang and try to find out what happens, and let usknow if you find out
;)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/