Opened 2 years ago

Closed 2 years ago

#16431 closed defect (fixed)

No Gadu-Gadu protocol support in 2.10.10 when internal libgadu is used

Reported by: arcctgx Owned by: tomkiewicz
Milestone: 2.10.11 Component: Gadu-Gadu
Version: 2.10.10 Keywords:
Cc:

Description

In the latest version of Pidgin there is a problem with Gadu-Gadu protocol if Pidgin is configured to use internal libgadu. Gadu-Gadu is not found in the list of available protocols anymore, and it's not possible to communicate with GG network.

As a workaround, user can either downgrade Pidgin to the previous version, or to install external libgadu and recompile Pidgin. Nevertheless, since the breakage occured at a minor bugfix release, I suppose it's worth looking into.

I'm using Pidgin package which comes with Slackware64 distribution. Here's the build info:

Arguments to ./configure: '--prefix=/usr' '--libdir=/usr/lib64' '--sysconfdir=/etc' '--mandir=/usr/man' '--enable-dot=no' '--disable-schemas-install' '--enable-dbus' '--enable-gnutls=no' '--enable-nss=yes' '--with-nss-includes=/usr/include/nss' '--with-nss-libs=/usr/lib64/' '--with-nspr-includes=/usr/include/nspr' '--with-nspr-libs=/usr/lib64/' '--disable-vv' '--enable-gtkspell' '--enable-cyrus-sasl' '--enable-perl' '--disable-meanwhile' '--disable-avahi' '--disable-nm' '--program-prefix=' '--program-suffix=' '--build=x86_64-slackware-linux' 'build_alias=x86_64-slackware-linux' 'CFLAGS=-O2 -fPIC' 'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig'

Print debugging messages: No
Plugins: Enabled
SSL: SSL support is present.

Library Support
Cyrus SASL: Enabled
D-Bus: Enabled
Evolution Addressbook: Disabled
Gadu-Gadu library (libgadu): Internal
GtkSpell: Enabled
GnuTLS: Disabled
GStreamer: Enabled
Mono: Disabled
NetworkManager: Disabled
Network Security Services (NSS): Enabled
Perl: Enabled
Tcl: Enabled
Tk: Enabled
UTF-8 DNS (IDN): Enabled
Voice and Video: Disabled
X Session Management: Enabled
XScreenSaver: Enabled
Zephyr library (libzephyr): Internal
Zephyr uses Kerberos: No 

Other people have also have this issue, as seen here: http://www.linuxquestions.org/questions/slackware-14/pidgin-no-gadu-gadu-protocol-after-upgrading-to-2-10-10-a-4175523815/

Attachments (1)

debug.log (16.2 KB) - added by arcctgx 2 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 2 years ago by datallah

  • Owner set to tomkiewicz

comment:2 Changed 2 years ago by tomkiewicz

I've heard of similar issue, but I don't remember the linux distribution name. The problem was internal libgadu linked to wrong gnutls version. I'm not sure why.

Have you tried recompiling Pidgin *without* installing external libgadu?

Debug log for startup could help.

Changed 2 years ago by arcctgx

comment:3 Changed 2 years ago by arcctgx

I recompiled Pidgin *without* external libgadu, the problem is still there.

In the debug info there's this message:

plugins: /usr/lib64/purple-2/libgg.so is not loadable: undefined symbol: gnutls_certificate_get_peers

I attached the full debug.log (IPs and port numbers are obfuscated).

comment:4 Changed 2 years ago by tomkiewicz

Which gnutls version do you use?

Have you had any warnings when compiling gg plugin?

Manual page doesn't mention any "since" or "deprecated" tags: http://man7.org/linux/man-pages/man3/gnutls_certificate_get_peers.3.html

Last edited 2 years ago by tomkiewicz (previous) (diff)

comment:5 Changed 2 years ago by mancha

Hello. I helped arcctgx solve this problem in a Slackware forum 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 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 2.10.10.

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. */
 #undef GG_CONFIG_HAVE_GNUTLS
-#ifdef HAVE_GNUTLS_2_10
+#if defined(HAVE_GNUTLS) && defined(HAVE_GNUTLS_2_10)
 #  define GG_CONFIG_HAVE_GNUTLS
 #endif

--mancha

comment:6 follow-up: Changed 2 years ago by tomkiewicz

Ah, it's definitely my fault. Thanks for figuring that out.

For me, the patch provided is good enough. For Pidgin 3.0.0, there will be no necessity for ssl support in libgadu, since it will be handled by libpurple (see tcpsocket module in the main branch).

Would you like to be listed in the ChangeLog for the work? Under what name?

Thanks,
Tomek

comment:7 in reply to: ↑ 6 Changed 2 years ago by mancha

Replying to tomkiewicz:

Ah, it's definitely my fault. Thanks for figuring that out.

For me, the patch provided is good enough. For Pidgin 3.0.0, there will be no necessity for ssl support in libgadu, since it will be handled by libpurple (see tcpsocket module in the main branch).

Would you like to be listed in the ChangeLog for the work? Under what name?

Thanks,
Tomek


Hi Tomek. You're very welcome.

For the ChangeLog, you can credit me as: mancha.

comment:8 Changed 2 years ago by Tomasz Wasilczyk <twasilczyk@…>

  • Milestone set to 2.10.11
  • Resolution set to fixed
  • Status changed from new to closed

(In [ca3ea8900dc9]):
Don't use GnuTLS, if it's disabled. Fixes #16431

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!