[Pidgin] #16431: No Gadu-Gadu protocol support in 2.10.10 when internal libgadu is used

Pidgin trac at pidgin.im
Tue Nov 4 14:46:45 EST 2014

#16431: No Gadu-Gadu protocol support in 2.10.10 when internal libgadu is used
 Reporter:  arcctgx  |       Owner:  tomkiewicz
     Type:  defect   |      Status:  new
Milestone:           |   Component:  Gadu-Gadu
  Version:  2.10.10  |  Resolution:
 Keywords:           |

Comment (by mancha):

 Hello. I helped arcctgx solve this problem in a Slackware forum
 protocol-after-upgrading-to-2-10-10-a-4175523815/#post5264246 thread].

 To save you from having to re-do the detective work I already did, here's
 my analysis:

 The problem gets introduced via commit
 [https://hg.pidgin.im/pidgin/main/rev/426067e03cfc 426067e03cfc].

 When a system builds Pidgin using NSS for SSL support (`--enable-
 gnutls=no` / `--enable-nss=yes`) and doesn't have a system libgadu, if the
 system does have GnuTLS>=2.10, you end up with `HAVE_GNUTLS` unset and
 `HAVE_GNUTLS_2_10` set. This is the case with Slackware 14.1 + Pidgin

 The result is the internal libgadu uses the GnuTLS API but libgg.so
 doesn't link the corresponding GnuTLS libs. Problem.

 Just having libgg.so link GnuTLS is probably not the way to go since
 users/vendors will justifiably believe `--enable-gnutls=no` prevents such
 a situation. One flexible solution might be a new configure option that
 allows systems that want to, to mix-and-match NSS (for everything but
 libgadu) and GnuTLS (for libgadu). At least until libgadu supports NSS.

 For now, the quick fix I provided was:

 --- a/libpurple/protocols/gg/lib/config.h
 +++ b/libpurple/protocols/gg/lib/config.h
 @@ -49,7 +49,7 @@

  /* Defined if libgadu was compiled and linked with GnuTLS support. */
 -#ifdef HAVE_GNUTLS_2_10
 +#if defined(HAVE_GNUTLS) && defined(HAVE_GNUTLS_2_10)



Ticket URL: <https://developer.pidgin.im/ticket/16431#comment:5>
Pidgin <https://pidgin.im>

More information about the Tracker mailing list