1

I installed bind-tools, the Arch linux alternative to dnsutils, but none of the tools work, all failing with the error:

host: error while loading shared libraries: libidn2.so.4: cannot open shared object files: No such file or directory

This problem with libidn2.so.4 seems to be a recent issue (January 2019) with Arch package builds and has apparently produced some pretty scary results, like making the entire system unbootable.

My questions are: (1) is the right approach to just wait until the maintainer of bind-tools fixes this problem, or to try to fix it myself? and (2) what exactly is going on? bind-tools requires libidn2.so.4 but does not install it? How could the maintainers possibly make such an error?

  • I have Arch Linux in my lab but I'm not able to reproduce your issue after having updated today. The symlinks /usr/lib/libidn2.so and /usr/lib/libidn2.so.4 exist pointing to /usr/lib/libidn2.so.4.0.0. All of the tools such nslookup and dig are working with no issue. If you ll /usr/lib/libidn2 and hit tab, does it return the actual library libidn2.so.4.0.0?. If so, you can just create the symlink yourself as suggested in the answer below. – Nasir Riley Jan 28 at 3:20
  • @NasirRiley My system does not have 4.0.0 on it, so if it is a dependency of bind-tools, then it is missing from the install because it did not get installed. My system has .0.3.4 on it – Tyler Durden Jan 28 at 3:36
  • 1
    @Nasir Riley Please never recommend -Syy ever again, as it is dangerous and can and will break your system, both because of the lack of -u and because of the presence a double -yy. See the warning here: wiki.archlinux.org/index.php/… – eschwartz Jan 29 at 18:18
  • @eschwartz I don't mean this as a personal attack, but it should be apparent that -Syy was a typo. I got the command from that same link that you suggested and I just left out the uu so I've already read it. I'm a human being who is prone to typos like everyone else. – Nasir Riley Jan 29 at 22:37
  • 1
    It is not apparent -- the internet is literally full of the advice to use -Sy or -Syy, and a typo which is also a valid command which happens to be dangerous, is statistically not going to be a typo. – eschwartz Jan 29 at 23:42
2

I don't run Arch Linux, so I'm going out on a limb a bit on this.

The article you linked to indicates it's a missing symbolic link, rather than a missing package. This makes sense, because normally in Linux, shared libraries will have at least two octets of version number after the '.so', and the error only mentions one.

My suggestion is that you run

ls -l /usr/lib/libidn2.so*

and see what it returns. If it just returns

/usr/lib/libidn2.so

and doesn't mention anything more specific, then I would recommend running

ln -s /usr/lib/libidn2.so /usr/lib/libidn2.so.0
ln -s /usr/lib/libidn2.so /usr/lib/libidn2.so.4

I'm suggesting running both, because it seems your program is looking for major version four of the library, but the article you referenced is looking for major version zero. This fix basically makes two aliases to the file /usr/lib/libidn2.so, one with a .0 and one with a .4.

If you see that there's a /usr/lib/libidn2.so.something.something, and the /usr/lib/libidn2.so is a symlink to it, it may make more sense to symlink to the more specific file. I don't really know which way would necessarily be best.

Another option for you would be to downgrade your libidn2 to the one before this issue.

As far as how this could happen - it looks like the maintainer of libidn2 for Arch Linux made a mistake. What baffles me is not that this happened at all but... that bug was added 12 days ago. A bug that can just be fixed with some manual symbolic links should take hours to fix, not weeks. I do not mean to disparage the Arch Linux maintainers; I have no idea what is happening on their side of things. It's just... frustrating. My guess is that this is just the tip of the iceberg of this story. In any case, people are people, and we all make mistakes. Somebody is probably already beating themselves up over this, and they don't need our help to do it.

  • I created that link and the tools worked, so I guess the existing so (which is libidn2.so.0.3.4) is just as good as libidn2.so.0.4 or maybe it was a typo omitting the .3? – Tyler Durden Jan 28 at 3:34
  • That could be. Or it's possible that the package used an automated linkage that assumed there would only be two numbers in released code, and it tried to link to libidn2.so.0.3 and didn't find it. Exactly how this happened isn't truly important to us; it's just something the Arch Linux maintainers need to work out and determine how to avoid. We're getting by for another day, that's good enough for us. – Ed Grimm Jan 28 at 4:03
  • 1
    Firstly, using ln to make a library that is not compatible and whose soname changed because it is not compatible, pretend to be compatible anyway, is a truly terrible idea as the application will load code which is silently corrupted and can do anything without warning. Second, nice assumption that Arch Linux maintainers broke anything, but have you even considered the possibility that it may have been user error? Telling users to blame someone else is fun, but isn't very productive, and it also makes for terrible answers. – eschwartz Jan 29 at 17:55
1

Since this is the sort of error that comes up a lot in Arch Linux, I've written a specialized script to analyze packages and determine if they are correctly built. (In 95% of cases the Arch Linux package is correctly built): https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries

Running this on the bind-tools package and looking for libidn2 shows that the latest version of bind-tools is linked to libidn.so.4:

$ pkg-list-linked-libraries bind-tools libidn2
==> checking linked libraries for bind-tools-9.13.5-4-x86_64.pkg.tar.xz ...
/usr/bin/dig
  NEEDED               libidn2.so.4
/usr/bin/host
  NEEDED               libidn2.so.4
/usr/bin/nslookup
  NEEDED               libidn2.so.4

Where does that library come from?

$ pacman -Qo /usr/lib/libidn2.so.4
/usr/lib/libidn2.so.4 is owned by libidn2 2.1.0-1

The bind-tools package in Arch requires the libidn2 package as a dependency, according to the output of pacman -Si bind-tools, which is well and good since it depends on it.

The versions of the two packages in the official Arch Linux repositories at the time of this writing correspond to the version of bind-tools and libidn2 that I've checked above:

$ expac -S '%n %v' libidn2 bind-tools
libidn2 2.1.0-1
bind-tools 9.13.5-4

So, you plainly have the latest version of bind-tools installed. But you claim you don't have the libidn2 libraries the binaries require. Why not? What is your version of libidn2 that is currently installed? Check the output of pacman -Q libidn2.

Since the package works for thousands of other people, my conclusion is that your system is broken, and you need to properly update your system in order to install the latest version of libidn2. See https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported for details on why this might happen, what to do to properly fix it, and why symlinking is not only not the solution, but will break your system even further.

As for the Parabola bug, that is the exact opposite problem. A completely different Linux distribution that is not Arch Linux, failed to rebuild their packages using the new libidn2, and as a result those packages were erroneously linking to libidn2.so.0

If you're really suffering from that Parabola bug, then you're not using Arch Linux at all, and you need to specify that you're actually using Parabola, because otherwise people won't know how to help you.

  • When I do pacman -Q libidn2 it results in libidn2 2.0.5-1. I don't understand why I need to upgrade my system (which already was done two weeks ago). If a package has a dependency, shouldn't it be doing any necessary upgrades for those dependencies? – Tyler Durden Jan 29 at 18:41
  • Again, Arch Linux does not support partial updates. This is a matter of policy, so it doesn't matter whether other Linux distributions support upgrading the dependencies of a package when doing partial updates -- if you want a distro that supports that, use the other distro which supports that. – eschwartz Jan 29 at 23:37

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.