For libclamav's SO version:
- We added two macros to clamav.h so we should increase Current and Age:
- CL_SCAN_PARSE_IMAGE and
- CL_SCAN_PARSE_IMAGE_FUZZY_HASH
For libfreshclam's SO version, we only made changes internal to the
library so we only need increase the Revision.
Ref: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
As of ClamAV 0.105, libjson-c is required.
There is also no option to disable libjson-c support.
This commit removes the dead code associated with the old build
option.
As of ClamAV 0.105, libz is required.
There is also no option to disable zlib support.
This commit removes the dead code associated with the old build
option.
As of ClamAV 0.105, libbz2 is required.
There is also no option to disable bz2 support.
This commit removes the dead code associated with the old build
option.
As of ClamAV 0.105, libxml2 is required.
There is also no option to disable PCRE support.
This commit removes the dead code associated with the old build
option.
As of ClamAV 0.105, PCRE2 is required. PCRE (1) is not an option, and
there is also no option to disable PCRE support.
This commit removes the dead code associated with those old build
options.
The delharc crate used to add LZH archive support appears to add
a dependency on macOS CoreFoundation library.
The error is:
[ 78%] Linking C shared library libclamav.dylib
Undefined symbols for architecture x86_64:
"_CFRelease", referenced from:
iana_time_zone::platform::get_timezone_inner::hc7da204717a39974 in libclamav_rust.a(iana_time_zone-bc4762a47da73d72.iana_time_zone.1863eb20d202562a-cgu.0.rcgu.o)
...
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libclamav/libclamav.12.0.2.dylib] Error 1
We already link with CoreFoundation for libfreshclam and clamsubmit, so
this commit extends that to libclamav as well.
json-c 0.17 defines the ssize_t type using a typedef on Windows.
We have been setting ssize_t for Windows to a different type using
a #define instead of a typedef.
We should have been using a typedef since it is a type.
However, we must also match the exact type they're setting it to or else
the compiler will baulk because the types are different.
Note: in C11, it's fine to use typedef the same type more than once, so
long as you're defining it the same every time.
common.rc is generated by CMake from common.rc.in.
But we do need to have it generate in the same directory as the other
resource files.
We simply forgot to remove common.rc after removing the Visual Studio
project files.
Change the version suffix from -devel-{TODAY} to -rc
Bump the SO version for libclamav and libfreshclam.
Increasing the current version to 12.0.0 and 3.0.0 respectively.
The reason is that we reintroduced using the version scripts:
- libclamav.map
- libfreshclam.map
- libclamunrar.map
- libclamunrar_iface.map
Note that libclamunrar and libclamunrar_iface use the SO version from
libclamav.
Note that libclammspack does not have a .map file and so is not getting
symbol versioning at this time nor are we bumping the SO version for
that library.
The MSI installer can find previous ClamAV installs to non-standard
locations such at D:\ClamAV instead of C:\Program Files\ClamAV but only
if upgrading to a new patch version of the same feature version.
E.g. can find an upgrade 1.0.0 to 1.0.1, but cannot automatically find
and upgrade 1.0.1 to 1.1.0.
This change will make it so all minor feature versions will store the
install path to the same key in the registry.
A consequence of this change is that you can no longer install multiple
feature versions of ClamAV using the MSI installer.
If you want multiple ClamAV minor versions installed on Windows you will
need to install using the ZIP package.
This change will not allow the MSI installer to automatically find and
upgrade across different major versions.
E.g. cannot find and upgrade 0.105.2 to 1.1.0 because the former is
major version 0, and the latter is major version 1.
This is intentional because it is more likely that there will be
breaking changes to config files and other user interfaces when we go to
ClamAV 2.0.0.
RPATH overrides the normal library search path, possibly interfering
with local policy and causing problems for multi-lib, among other issues.
Add an option to avoid setting it with letting it enabled by default.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
On distros with multiple python impls it can be useful to select
a specific version rather than whatever CMake thinks is appopriate.
This patch enables users to instruct CMake to look for a specific
version of python by passing `-DPYTHON_FIND_VER`.
Building with these will fail for Clang because _GNU_SOURCE is not
defined.
-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=strict-prototypes
Also added fix to use "MATCHES" instead of "EQUALS" in FindLLVM where
the same sort of logic is used.
The libclamav SO ABI has changed since 0.103 due to:
- Removal of the CLAMAV_PUBLIC namespace by no longer using libclamav.map
- Change of: extern const char *cl_strerror(int clerror);
To: extern const char *cl_strerror(cl_error_t clerror);
See: e66c00f41c/libclamav/clamav.h (L1203)
- Introduction of Rust symbols to namespace.
Ref: https://github.com/Cisco-Talos/clamav/issues/775
As such, it seems fair to increase the SO version.
This is an amendment to this prior change for the ClamAV 1.0.0
version bump:
0dd6ab3f16
Instead of incrementing SO Current version to 11, and Age to 2,
we'll increment SO Current version to 11, and reset Age to 0.
So the SO version will effectively go from:
9.1.0
to:
11.0.0
ClamAV requires non-default build options for TomsFastMath to support
bigger floating point numbers. Without this change, database and
Windows EXE/DLL authenticode certificate validation may fail.
The option to build with an external TomsFastMath library should be
removed. The `ENABLE_EXTERNAL_TOMSFASTMATH` build should be ignored,
with some sort of warning.
This commit removes the option. If used, the build will not fail, but
CMake will print a warning that the unused option was ignored.
In preparation for the release candidate, changing the version suffix
from devel to rc.
Increment SO current version to 11, because we added to the public API.
Increment SO age to 2, because we didn't change anything or remove
anything from the public API.
Added functionality level values to the bytecode API enum for recent
patch versions.
The bytecode source files largely use `int` instead of the appropriate
`cl_errot_t` for clamav status codes, as well for boolean variables.
This hides warnings that would indicate bugs, and makes it harder to
read the code.
I haven't gone as in depth as with some other code cleanups. This
largely just replaces function interfactes and ret variables that use
`int` with `cl_error_t`. I also swapped a couple of `int`s to `bool`s.
While doing so I found that the `cli_bytecode_context_setpdf()` function
was incorrectly placed in the `bytecode_api.c` file instead of the next
to similar functions (`cli_bytecode_context_setpe`, etc.) in bytecode.c.
It's not an API function, so I moved it to the correct location.
I also eliminated a couple of compiler warnings:
- LLVM's CFG.h header emits a warning about a multi-line comment, so
that crops up with using LLVM for the bytecode runtime.
I disabled the warning through CMake.
- C doesn't like using the `inline` keyword on cli_dbgmsg in the
declaration in `bytecode2llvm.c` because we're compiling the bytecode
runtimes as a separate object file from the rest of libclamav.
It doesn't appear to be a functional issue, but I swapped that file
over to use `cli_dbgmsg_no_inline()` instead, just in case.
I would hope link-time-optimization will inline it anyways.
A copy-paste error in the markdown support for building the macOS-
installer caused an issue where markdown module may be accidentally
used instead of pytest. Strangely, this still worked okay up until we
converted the clamscan tests into a directory of tests, at which point
the `python3 -m markdown` invocation was upset that it was trying to
execute a directory instead of a .py file.
This commit removes the line that overwrites the python test command
with using the markdown module.
We already set the default build type to RelWithDebInfo for CMake, but
we were setting it *after* adding the Rust module. We need to do it
before, or else the Rust stuff will still default to Debug, which makes
for really slow scans of images that get fuzzy hashed.
CMake has a pretty sweet alternative to pkg-config or to the older
`package-config` script that you'd run with `--libs`, `--ldflags`, etc.
CMake can (optionally) install a YourPackageConfig.cmake alongside your
libs under `<prefix>/lib/cmake/<pkg>/<pkg>Config.cmake`.
If you build something with -D CMAKE_FIND_PACKAGE_PREFER_CONFIG=TRUE,
then it will find that and use that to bring real CMake targets into
your build system for your dependencies, guaranteeing that you get all
the right include paths, library paths, ldflags, etc.
See: https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_PACKAGE_PREFER_CONFIG.html
This works great for us for Curl and LLVM... not so much for libxml2.
Ideally we'd figure out what's wrong and support libxml2's package
config.cmake file, but for now this workaround lets us ignore libxml2
and continu to use this feature for the other libs, like LLVM.
We must pass the LLVM library dependencies to the libclamav_rust
build.rs script so it links the libclamav_rust unit test executable with
LLVM.
Also:
- We can remove the libtinfo dependency that was hardcoded for the LLVM
3.6 support, and must remove it for the build to work on Alpine, macOS.
- Also, increased the libcheck default timeout from 60s to 300s after
experiencing a failure while testing this.
- Also made one of the valgrind suppressions more generic to account for
inline optimization differences observed in testing this.
Modified bytecode JIT code to support llvm versions 8, 9, 10, 11, 12.
Additionally updated FindLLVM.cmake to the current version, found at
https://github.com/ldc-developers/ldc/blob/master/cmake/Modules/FindLLVM.cmake,
as well as making modifications suggested by Micah Snyder to check VERSION_LESS
in CMakeLists.txt to avoid having modifications to FindLLVM.cmake.
Add support for compiling with external TomsFastMath library provided by
the system instead of compiling the vendored copy into libclamav.
The vendored source is still built directly into libclamav instead of as
a separate library the way libmspack is done.
The rationale is that:
A) it's more complicated to deal with possibly compiling as static or
dynamic, and also
B) libmspack and libunrar are compiled separately primarily because of
licensing concerns. TomsFastMath public domain, so that isn't a concern.
Resolves: https://bugzilla.clamav.net/show_bug.cgi?id=12562
Micah Snyder