ISC has released BIND 9.2.3, which among other things contains an update for the so-called "Verisign" patch (otherwise known as "Delegation-Only"). I've created an ebuild for the new version but am running into some hitches with regards to libisc.so.4 (installed by 9.2.2) and libisc.so.7 (installed by 9.2.3) being apparently incompatable. Merging BIND a twice in a row seems to mitigate / remove the problem, but I'm looking for input to remove that as a possibility. :)
Created attachment 19899 [details] BIND 9.2.3 ebuild
I ran into the same (?) problem with the libisc and libdns libraries. After upgrading to 9.2.3 from 9.2.2-r3, bind would not start. It complained: /usr/sbin/named: error while loading shared libraries: libisc.so.4: cannot open shared object file: No such file or d [ !! ] and /usr/sbin/named: error while loading shared libraries: libdns.so.10: cannot open shared object file: No such file or directory [ !! ] I 'fixed' this by creating the following symlinks in /usr/lib: cvs lib # ln -s libisc.so.7.0.1 libisc.so.4 cvs lib # ln -s libdns.so.11.0.2 libdns.so.10 So far, everything seems to be working. Anyway, I find it strange that this came up at all. :| It sounds like there may be something wrong in the build process, but I'm not sure what it could be ?
From what I've observed, when BIND 9.2.3 builds it links against the previously installed version of the libisc (and apparently libdns) library, the new version installs its own, updated versions of the libraries and when the previous version is uninstalled, the dependant libraries are removed. Perhaps a few symlinks are in order. I've updated the ebuild to create the appropriate symlinks, so I'm looking for people with bind <=9.2.2-r3 to upgrade to 9.2.3 and tell me if it starts painlessly.
I had this problem too, and was (quite) surprised to find libisc.so.4 in the root (/). Something misplaced it there?
seems that every package need to be rebuilt #rev-depend
yes #revdep-rebuild fixed this
Logically, you could always make bind block itself (I think - not tried it), but I think I can come up with a better way...
The library sym links do not get created correctly; dosym is called with two unprefixed arguments and automatically prefixes its second argument with ${D}, resulting in the link being created in the root directory. /usr/lib should prefix the link names.
Symlinks will work for a quick hack, but we really should figure out what exactly it is in the build process that is causing it to link against old libraries. I believe it has something to do with libtool, but I don't have enough experience with it to say for sure. Any libtool/autoconf experts out there?
Ok, the good news is the dosym stuff is fixed (never rush out an ebuild. {kick, kick} ), the bad news is it's apparently an uphill battle; /usr/sbin/named: error while loading shared libraries: libdns.so.8: cannot open shared object file: No such file or directory This would make the third library I'd have to kludge and I get the feeling there are other potentials making this 'hack' a very short-term thing. Anybody out there investigated the build process enough to shed some insight?
*** Bug 37700 has been marked as a duplicate of this bug. ***
Ebuild is in the tree, but Bug #32908 remains an issue.
Provided a new diff against the bind-9.2.3.ebuild on portage. Get the details http://bugs.gentoo.org/show_bug.cgi?id=32908
