* Added loglevel parameter to logg()
* Fix logg and mprintf internals with new loglevels
* Update all logg calls to set loglevel
* Update all mprintf calls to set loglevel
* Fix hidden logg calls
* Executed clam-format
Previously we'd not clang-formatted the c++ bytecode files because:
A) It's a massive difference in format
B) I wasn't sure, at the time, which code was "ours"
Reformatting now that the LLVM source is all removed and before it gets
updated to support modern LLVM versions.
Have to manually link libtinfo (`-ltinfo`) because our FindLLVM
didn't add it to the LLVM_LIBRARIES variable for us. See:
- https://stackoverflow.com/questions/21477407/llvm-3-5-fails-to-link
Have to remove the CXX_STANDARD setting at the top of CMakeLists.txt
because of c++90 / c++11 ABI compatibility issues w/ LLVM. See:
- https://maleadt.github.io/LLVM.jl/dev/man/troubleshooting/
Rename "llvm/Config/config.h" "llvm/Config/llvm-config.h" because
LLVM renamed it in 2.8.
Have to link LLVM manually with the test binaries that use the
clamav object library instead of libclamav shared library.
CMake does not propagate library dependencies from object files.
I tested on ubuntu:16.04 with LLVM 3.6 built from source using:
```
/usr/local/bin/cmake .. -D CMAKE_INSTALL_PREFIX=/opt/llvm/3.6 \
-D LLVM_ENABLE_RTTI=ON
```
Then built clamav w/:
```
/usr/local/bin/cmake .. -D CMAKE_INSTALL_PREFIX=`pwd`/install \
-D BYTECODE_RUNTIME="llvm" \
-D LLVM_ROOT_DIR="/opt/llvm/3.6" \
-D LLVM_FIND_VERSION="3.6.0" && make && make install
```
Internal version is an LLVM 2.8 with 2 patches backported from LLVM 2.9 to fix a
crash on AVX chips.
So drop support for building with external LLVM 2.8, and add support for
building with external LLVM 2.9 instead.
Caveat:
stack smashing protection is broken on LLVM 2.9 so it is disabled
Example on Debian:
apt-get install llvm-2.9-dev
./configure --enable-llvm --with-system-llvm=/usr/bin/llvm-config-2.9
With -m32 LLVM gets the target arch right, and configure gets it wrong.
LLVM's detection always overrides the arch, so don't warn on these mismatches.
startup.cbc will get the correct arch when JIT is available, which is the only
case where the arch matters anyway.
When there is no JIT the arch reported to startup.cbc will be configure's which might be wrong.
But since there is no JIT startup.cbc shouldn't need to check the arch anyway.
It will still be able to detect sparc vs x86 though, not 32 vs 64-bit.
mko-x