Just upgraded to 18.04, and when I run sudo apt update, it complains:

/usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so: symbol gnutls_pkcs11_privkey_init version GNUTLS_3_4 not defined in file libgnutls.so.30 with link time reference Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so

Older info:

Running gio version gives: 2.53.6

Running gntls-cli -v gives: gnutls-cli 3.5.8

As far as I can tell, this means that apt-get wants to use GNUTLS version 3.4, when I have 3.5.8.

Any ideas on how to proceed would be appreciated. My suspicion is that perhaps it did not resolve the dependencies correctly when upgrading distros or is trying to update from the wrong repositories.

Interestingly, I get the same error when opening Octave (https://www.gnu.org/software/octave/).

Added in response to comment:

apt-cache policy libgnutls30 says:

  Installed: 3.5.18-1ubuntu1
  Candidate: 3.5.18-1ubuntu1
  Version table:
 *** 3.5.18-1ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

/usr/lib/x86_64-linux-gnu/libgnutls.so.30 points to libgnutls.so.30.14.10 for me

nm -D /usr/lib/x86_64-linux-gnu/libgnutls.so.30 | grep GNUTLS_3 prints 0000000000000000 A GNUTLS_3_4

  • 1
    What does apt-cache policy libgnutls30 say? My bionic system shows gnutls-cli 3.5.18 however /usr/lib/x86_64-linux-gnu/libgnutls.so.30 points to libgnutls.so.30.14.10 and nm -D /usr/lib/x86_64-linux-gnu/libgnutls.so.30 | grep GNUTLS_3 shows GNUTLS_3_4 – steeldriver Aug 15 '18 at 18:47
  • 1
    Thanks, just added this info to the question--I am seeing the same output as you for those commands, although I don't know enough to understand what it means. – Zach Boyd Aug 15 '18 at 18:54

Here is how I solved the issue. Note that it seemed a bit dangerous at the end, so a safer approach in another answer or in comments would be appreciated.

I found out there are two versions of libgnutls.so.30 on my system, one in /usr/lib/x86_64-linux-gnu and the other in /usr/local/lib/.

Running nm -gC and readelf -sW with grep on these files shows that the first one does contain the symbol in question and the second does not. This leads me to believe that the wrong copy of gnutls is being loaded at run time.

The file in /usr/lib/x86_64-linux-gnu is a link to libgnutls.so.30.14.10, and the one in /usr/local/lib/x86_64-linux-gnu is a link to libgnutls.so.30.13.1.

Confirmation: Running ldd on libgiognutls shows that it does try to link to the /usr/local/lib version.

More confirmation: Changing LD_LIBRARY_PATH did not work. Looking through the ld.so man page shows that this is probably because some elevated privilege is attained by the time ld.so is called.

Doing sudo su and then changing LD_LIBRARY_PATH. At this point, I am convinced that it is the link priorities of the two versions of libgnutls that is the issue.

Solved: I just took a leap of faith and linked the /usr/local/lib/libgnutls.so to /usr/lib/x86_64-linux-gnu/libgnutls.so file and the same with the .30 versions as well. So far nothing has broken and the error messages are gone.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.