On Fri, 19 Nov 2004, Thomas Lamy wrote: > The includes are found, obviously. Your problem are the libraries. > Let's have a look: > # ldd /usr/lib/libclamav.so.1.0.4 > libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x40049000) > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x40059000) > libcurl.so.3 => /usr/lib/libcurl.so.3 (0x40087000) > libidn.so.11 => /usr/lib/libidn.so.11 (0x400b7000) > libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x400e7000) > libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x40118000) > libdl.so.2 => /lib/tls/libdl.so.2 (0x40215000) > libz.so.1 => /usr/lib/libz.so.1 (0x40218000) > libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4022b000) > libnsl.so.1 => /lib/tls/libnsl.so.1 (0x4023a000) > libc.so.6 => /lib/tls/libc.so.6 (0x4024f000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > This is on a Debian box though. Note that at least here the ssl > libraries are in uncommon places. Would you mind to do a > find /usr/local/lib -name libcrypto.so\* -print > and see what you get?
Actually libcrypto.so resides in /usr/local/ssl on my box. find /usr/local/ssl/lib -name libcrypto.so\* -print /usr/local/ssl/lib/libcrypto.so.0.9.7 /usr/local/ssl/lib/libcrypto.so.0 /usr/local/ssl/lib/libcrypto.so /usr/local/ssl/lib/libcrypto.so.4 But that's not the problem. Tomasz pointed me in the right direction when he told me to try --without-curl. Sure enough that worked. My curl install was version 7.10.6 IIRC (I've already replaced it and I forget what it was now). After the succesful compile without curl I compiled 7.12.2 and recompiled clam without the disabling of libcurl support that time. Sure enough it worked like a charm. I don't know what the minimum version of Curl is that Clam requires but 7.12.2 certainly worked. That should probably be put in the README or FAQ sometime. It's an easy upgrade. > > I'm trying to get ClamAV >=0.80 working to help take the strain off the > > servers with the new DNSDatabaseInfo option. Unfortunately I'm stuck and > > not able to do that until I can get around this problem. Has anyone else > > seen anything simliar? The rest of my system is working fine. I compile > > things all the time with OpenSSL support and never have trouble. I didn't > > mention it earlier but no there are no header or library conflicts with > > the OSSL RPMs hanging around. Everything has been cleaned up nicely and > > the duplicates have been neutralized. I'm at a loss on this one. If no > > one else is experiencing this problem then it must either be my setup or > > something I'm doing. Everything else seems to be working fine though so I > > suspect the problem is elsewhere. A fresh look on this problem would > > certainly help though. Tomasz, any ideas for me? I'm stumped. > > > > Thanks > > Justin > After all it _might_ be an autoconf issue, but this is the first report > I ever read about this. I've experienced autoconf issues w/ SSL before. MySQL is a classic one. They had a bug for well over a year that always assumed SSL libraries on RH boxes were in the standard RH place. Setting CFLAGS and CPPFLAGS didn't help one bit. The solution required hacking up the MySQL source. It was pretty ugly. After I inquired about it some user on the MySQL mailing list sent me a patch that was widely distributed to fix the problem. For some reason the developers refused to fix the problem themselves. The own personal little war against certain library paths I guess. Oh well. I think it finally works now. Thanks for the reply, Justin _______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
