RE: [Tcl-nap-users] broken install on linux?

[Edward K. <Edw...@cs...>]

On Tue, 16 May 2006 ni...@ma... wrote:

>
> >
> > tcl_library = /usr/local/ActiveTcl/lib/tcl8.4
> >
> > couldn't load file "/usr/local/ActiveTcl/lib/libnap5.0.so": libssl.so.4:
> >
> >
> > cannot open shared object file: No such file or directory
> >
> >
>
> I think you want to do an
>
> "ldd libnap5.0.so" to check dependencies...
>
> It could be your libssl is a different version as indicated in your
> message...Try a simple link first ("ln -sf ...")
>
> Finally, make sure that /usr/lib is in your /etc/ld.so.conf file (I cant
> image in that it wouldn't be..)
>
> regards,
>
> nikos

Thanks for the pointer Nikos.

It seems that sometime recently the libssl shared object went up a version,
from 3 to 4.  The distributed binary was linked against version 4, so all the
boxes with version 3 are unhappy.  A solution is to get hold of updated libssl
packages for your linux distribution and install them.  After doing that you
MUST run ldconfig so that it rebuilds its list of shared objects.

When I did this (on RedHat Fedora 4) it seemed happy, but then I ran into
exactly the same problem again with libstdc++.

The shared object system is working in as much as it is supposed to make sure
you don't link at runtime with an earlier version of the library than the
application was built against - it just happens to be annoying, since I
suspect it is very unlikely that this application (NAP) is using any features
that are new in libssl.so.4 compared with libssl.so.3.

The solution is probably to distribute a binary built on an oldish
distribution, or for everyone to upgrade their boxes with the latest
distributions and/or packages.  An alternative would be to build NAP from
source on the box you want to run it on.

Regards, Edward.

PS: According to the man page, ldconfig trusts files in /lib and /usr/lib by
default and automatically includes them, so there is no need for those
directories to be explicitly listed in /etc/ld.so.conf.