In the test lab, when I updated Bind from version 9.7.3 to version 9.9.11, the following error occurred: liblwres.so.60: Cannot Open shared.

From what I've researched, it seems that I have to install bind-libs, in the compatible version. I didn't find this package on slackware ftp for version 13.37.

I know that the Slackware 13.37 server is a very old system, but it is what we have in production, and in order for me to update I have to present my boss with a very consistent plan.

The problem is that Slackware 13.37 is EOL since 6. April 2018, meaning no further updates are being released for that version of the distribution.

I'm guessing you're updating BIND due to there being some security flaw that needs patching? In that case, these are your options:

1. Install the required libraries from a more recent Slackware release
2. Build and install the libraries yourself
3. Compile and install BIND from the source code
4. Upgrade the server to a supported version of Slackware

Option 1 will result in a weird Slackware-hybrid that isn't supported in any way. And you'll most certainly experience other dependency issues.

Options 2-3 will probably also mean you'll have to chase down and fix a number of dependencies along the way, so it'll be even more work and you'll still end up with something that's unsupported and has to be patched manually.

Option 4 will work and give you a secure and supported platform. 13.37 is a bit long in the tooth, so you may want to consider doing the upgrade in multiple steps, via 14.0 and 14.1 to 14.2. There are some possible pitfalls related to (among other things) NIC firmware and the kmod package which you could avoid by doing it that way.

You may be able to deduce from this which of the above I would recommend.

The problem was that I configured bind in chroot, and when starting rc.bind he was calling the libraries of the old version still. After I copied the new binaries from /usr/sbin to /var/named/chroot, it worked normally!

Luckily, you have a lab setup so you can try out different combinations of OS version and applications.

Do the applications actually have dependencies on Bind? (Did they actually make major configuration changes to a point release??!!) I think I'd simply backup the Bind configuration files, and restore them onto a fresh, up-to-date SW test installation and see how it goes on your test network.

If there are non-Bind applications to worry about: What applications is this system running? How are they installed? (packages? sources?) How dependent are any "production" applications on 13.37 itself?

I've had applications that were built from sources and installed under "/opt". (Sometimes just be closer to current when a distibution's repository is lagging behind.) If I were to upgrade the base OS, I could then remount /opt, and see if the applications are still working as they should be. If not, I could make a parallel tree of the sources (in /opt/src/appname-new-version), recompile using the new OS's libraries, redefine the symlink pointing to the application's new binary/lib tree before running "make install", and test, test, test (deleting the old tree after passing tests). In the past, I've kept "configure" command lines in scripts to allow me to recompile with the exact same options---not sure how well that plan works with Slackbuilds if you've been going that route.

HTH...