LD_LIBRARY_PATH needed in shell

English Applications
1

I apologize in advance if this is a ClamAV problem insted of an OpenSuse problem. (It turned out it is a different way of doing things problem).

I installed the version of ClamAV that is provided by OpenSuse. The problem with that is that when a new version of ClamAV shows up I constantly get complaints when I run both freshclam and clamscan for at least three weeks when my version of ClamAV supplied by OpenSuse goes out of date. So I uninstalled the clamav OpenSuse provides using the GUI software control panel. Then I downloaded the source and the signature from ClamAV. It verified. I first tried to do a ./configure (as root) but it said I needed a clamav user. So I created:

Group: clamav (2001)
User: clamav (2001)

I picked the UID / GID to be that to avoid collisions with what ever you may have. After that the configure, make and install went fine. I then edited both the clamd.conf file and freshclam.conf files in /usr/local/etc. There was a bit of path confusion problem with the old freshclam and the new one so I did a ^D in my su’d xterm, and then su’d again. This time it showed the following for where things are:

whereis freshclam

freshclam: /usr/local/bin/freshclam /usr/local/etc/freshclam.conf

which freshclam

/usr/local/bin/freshclam

But when I run freshclam I get:

freshclam

freshclam: error while loading shared libraries: libclamav.so.6: cannot open shared object file: No such file or directory

Huh? So I see if the libarary is there:

cd /usr/local/lib

ls -l libclamav.*

-rwxr-xr-x 1 root root 1017 Oct 3 01:09 libclamav.la
lrwxrwxrwx 1 root root 18 Oct 3 01:09 libclamav.so -> libclamav.so.6.1.5
lrwxrwxrwx 1 root root 18 Oct 3 01:09 libclamav.so.6 -> libclamav.so.6.1.5
-rwxr-xr-x 1 root root 12929399 Oct 3 01:09 libclamav.so.6.1.5

/usr/local/lib is in the /etc/ld.so.conf file, so why can’t freshclam find the library? Is ClamAV using a shell environment variable? In the past I was on RedHat / Fedora and had no problems rolling my own ClamAV, but if my memory is correct they did have a library path in shell. Never mind. I just tried this and it works:

export LD_LIBRARY_PATH=**************

(all of stuff in the /etc/ld.so.conf file except the last line, colon “:” seperated)

I suggest adding a LD_LIBRARY_PATH environment variable to the various shells to avoid this problem in the future. There is bound to be other stuff besides ClamAV that uses LD_LIBRARY_PATH instead of the etc/ld.so.conf file. The puzzling thing is that this variable was not shown in the bash man page. I have no idea where it belongs, but bash will be the first place somebody may check for the name of the library path environment variable. The only reason I mention this is that on some 'nix systems it seemed to use something else on LD_LIBRARY_PATH. I hope by now everybody has standardized on LD_LIBRARY_PATH.

2

I can’t answer your question. Except to say. When I tried it one time, the version from the repo works.
I just never install it, not for at least 4 years now.
But I would stick with the repo version if you think you need it.

3

Probably you forgot to run ldconfig.

It’s not ClamAV that uses LD_LIBRARY_PATH, it’s the dynamic linker. As so, the variable is documented in man ld.so. Setting LD_LIBRARY_PATH by default would be a very bad idea.

4

It is not so much as I forgot, as I never knew about ldconfig. I am coming from an old Unix background which explains why I was initially baffled:

Solaris FAQ

But I also never had to use ldconfig on RedHat / Fedora (for some reason). That was despite me installing ClamAV in /usr/local and doing NOTHING to handle where the libraries were at. I assume that they may have modified something that if the library was not found in the cache that it created the cache entry on its own. I also remember that at least at one time it had the LD_LIBRARY_PATH environment variable. I wouldn’t know if it still has it because I stayed with Fedora 3 forever and then switched to OpenSuse and Ubuntu. I am sorry, but I don’t have time for a new OS more than every 2-4 years. Most ordinary people are just like me. They don’t have time to install 2-3 new OS per year. Heck, they don’t even have time for even a new OS every year. Hopefully, three years from now ldconfig will still be the way to handle this. Get the idea? There is too much volatility to keep up with all of these changes.

It is just that I was used to LD_LIBRARY_PATH. You are correct of course that it is the dynamic linker that is using it and the ld.so man page is where you want to find the info. I did notice that the only valid directories I had in my /etc/ld.so.conf file were /usr/X11R6/lib and /usr/local/lib. I think you need to give the information on why ldconfig is superior to LD_LIBRARY_PATH. From what I have read it creates the /etc/ld.so.cache file which is a hash table so you don’t have to open up the directories one at a time and search for the library file that is needed. It is also contains other information about each file to help the link loader. I assume it makes things run much faster. But on Sun Solaris I think I may want to continue using LD_LIBRARY_PATH over the alternative (see the above web page). I haven’t looked at how this is done on the latest versions for FreeBSD / OpenBSD yet.

THANKS!