Question

I am running OS X server 10.8 ClamXAV is built in. I have installed and am running squidman (Squid proxy server). I'd like to install HAVP and get it up and running.

The error I get when I ./configure in the HAVP directory:

checking for ClamAV scanner library... clamav-config not found

 Error finding ClamAV installation!  Add ClamAV binaries path to PATH and run configure again.

 To disable ClamAV library support, use --disable-clamav.

The location of clamav-config:

mail:local everett$ cd /usr/local/clamXav/bin

mail:bin everett$ ls

ClamXavProxyHelper  clamconf        freshclam
RunFreshclam        clamdscan       sigtool
clamav-config       clamdtop
clambc          clamscan

My path:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/usr/local/clamXav/sbin:/usr/local/clamXav/bin

So, what is going on, and how do I make this (the HAVP install) work?

EDIT New error after ./configure succeeds, and I try make:

cd havp && make
g++ -g -O2 -I/usr/local/Cellar/clamav/0.97.6/include -Wall -g -O2 -DHAVE_CONFIG_H -c -o scannerhandler.o scannerhandler.cpp
In file included from scannerhandler.cpp:26:
scanners/clamlibscanner.h:37: error: field ‘limits’ has incomplete type
make[1]: *** [scannerhandler.o] Error 1
make: *** [all] Error 2

EDIT 2 There was an update to HAVP (from version .88 to version .92a). Running the install on the update succeeded.

Was it helpful?

Solution

The error message is hard evidence that the configure script is getting no output when it tries to run clamav-config but unfortunately the "not found" part is an arbitrary assumption in the script, not a result of actual runtime analysis of the failure. There are multiple possible causes for the failure:

  1. The configure script isn't seeing what you say is in your $PATH. There are multiple potential root causes for that but one way to rule it out: look in config.log for lines near the top starting with "PATH: " to confirm what the script saw in $PATH.
  2. The permissions for the clamav-config script don't allow the user you are running configure as to execute it. This would be repaired with 'sudo chmod 755 clamav-config'
  3. Your clamav-config script actually has an empty string as its $prefix value. That would be a bad botch in how clamav was installed, but it might not cause any problems until you try to build something that depends on it. The check would be to look in clamav-config, the fix would be to do a proper clamav install.
  4. Mountain Lion's sandboxing is blocking the execution of clamav-config by configure. I'm not really sure how to fix this, but the denial should be logged. I'm not sure if ML saves those to any text log, but a suitable 'syslog' invocation will show them (see 'man syslog' for gory details)

Side note: #4 is why I've held off moving significant machines to ML. On my guinea pig system there are chronic sandboxing violations by Apple's own programs being blocked, which zeros out my faith that Server components will not break.

OTHER TIPS

Looking at the source of this thing (HAVP) I see the makefile is unlikely to be the culprit. The configure and the configure.in seem more interesting.

Try this command:

clamav-config --prefix 2>/dev/null

what does it return, if anything at all? It is used in the config files as:

clamprefix="`clamav-config --prefix 2>/dev/null`"
clamversion="`clamav-config --version 2>/dev/null`"

to determine prefix and version of clamav. Sorry all I can suggest is a starting point, but I hope it's better than nothing.

Licensed under: CC-BY-SA with attribution
Not affiliated with apple.stackexchange
scroll top