[Pkg-xmpp-devel] gsasl_1.4.0-2_i386.changes REJECTED

Simon Josefsson simon at josefsson.org
Fri Feb 5 14:38:26 UTC 2010


cascardo at minaslivre.org writes:

> I've done similar experiments here and my program worked all right too.
> So, I thought I've missed something that we had back in the days we had
> a problem with dicod. But, then, you've tried everything we dicod and it
> works nicely too.

Yeah, we may still be missing something, but everything I've tested so
far seems to work -- the warning message that is printed by rtld is the
only exception.  I'm going to file a glibc bug about that, though, since
it makes adopting version scripts for shared libraries more difficult.
It is not a critical problem, though.

> But, anyway, we've been having problems with other programs. Basically
> the issue seemed to be an old gcrypt version, right? So, we just need to
> investigate now how we can make gsasl pull the right version
> automatically.

The libgcrypt issue is very different!  It has nothing to do with shared
library versioning.

The libgcrypt problem is triggered by this code in libgsasl:

      if (gcry_check_version (GCRYPT_VERSION) == NULL)
        return GC_INIT_ERROR;

In other words, if libgsasl is used (during runtime) with a libgcrypt
version OLDER than it was built with, it will refuse to work.  This
happened here because libgsasl was built against libgcrypt in unstable,
and libgsasl entered testing but libgcrypt did not -- so users installed
the broken libgsasl.

This problem is fixed by adding a >= dependency on the libgcrypt version
used when building libgcrypt.  It would be nice to find an automatic way
to deal with this, but I don't know how to...

> And I think that's why we have the symbols and the old shlibs files. I
> think we must push that into gcrypt package. What do you think?

That is not require to fix the libgcrypt issue.

/Simon



More information about the Pkg-xmpp-devel mailing list