LLVM older than version 3.8 is no longer supported on MacPorts for macOS 10.12 (Sierra) and newer:

While building on Sierra this error message appears:
"Error: llvm-3.6 is not supported on macOS Sierra or newer.
Error: org.macports.fetch for port llvm-3.6 returned: unsupported platform"


See also the comments on:

MacPorts ticket 52206: llvm @3.5 build fails on macOS Sierra
https://trac.macports.org/ticket/52206
especially
https://trac.macports.org/ticket/52206#comment:1

MacPorts ticket 52424: Ports that depend on old llvm versions should be updated
https://trac.macports.org/ticket/52424
especially
https://trac.macports.org/ticket/52424#comment:8

[macports-users] mailinglist: LLVM not supported on Sierra?
https://lists.macosforge.org/pipermail/macports-users/2016-October/041707.html
especially
https://lists.macosforge.org/pipermail/macports-users/2016-October/041719.html



Please make clamav capable of LLVM 3.8+.

Please use './configure --enable-llvm=no' until this can be resolved. This is a workaround which uses the byte code interpreter rather than the LLVM bytecode JIT to execute the ClamAV byte code signatures.

*** Bug 11630 has been marked as a duplicate of this bug. ***

(In reply to Steven Morgan from comment #2)
> Please use './configure --enable-llvm=no' until this can be resolved. This
> is a workaround which uses the byte code interpreter rather than the LLVM
> bytecode JIT to execute the ClamAV byte code signatures.

Could the side effects / differences of llvm vs byte code interpreter be 
described somewhere?
I believe there is no difference if "Bytecode false" is set in the config file.
With the option enabled it is (I have been told) it is slightly slower if llvm is not used but then again I have no numbers here. Also there is no loss in functionality.

Comment 18 of bug 11309 will be of some help, I think.

(In reply to Steven Morgan from comment #2)
> Please use './configure --enable-llvm=no' until this can be resolved. This
> is a workaround which uses the byte code interpreter rather than the LLVM
> bytecode JIT to execute the ClamAV byte code signatures.

It builds and works perfectly with external LLVM <= version 3.7, for instance installed via MacPorts, see:

bug 11309#c29 https://bugzilla.clamav.net/show_bug.cgi?id=11309#c29
bug 11309#c32 https://bugzilla.clamav.net/show_bug.cgi?id=11309#c32

Restriction to 3.7 and lower caused by this little line in:

$ find ./configure* -print | xargs grep -n "LLVM < 3.7 required, but"
./clamav-devel/libclamav/c++/configure:16611:    as_fn_error $? "LLVM < 3.7 required, but \"$llvmver\"($llvmver_test) found" "$LINENO" 5
./clamav-devel/libclamav/c++/configure.ac:99:    AC_MSG_ERROR([LLVM < 3.7 required, but "$llvmver"($llvmver_test) found])

Unfortunately, MacPorts has ceased support for LLVM <= version 8 since macOS 10.12 (Sierra), so that even updating a local installed and perfectly working LLVM 3.7.1 via MacPorts on Sierra fails with the message given in comment 1.

If at least this restricting test to version < 3.7 namend above at these two lines in clamav's c++/configure (line 16611) and c++/configure.ac (line 99) file would not exist or conveniently could be made more relaxed, so that it wouldn't bother about a installed current stable LLVM 3.8 via MacPorts, that would be fine.

TLDR: libclamav prevents an external system's LLVM < 3.7, only permits version 3.6 or lower per this one named line in c++/configure and c++/configure.ac, and MacPorts now allows only LLVM >= 3.8 to be installed on macOS Sierra; older installed (and so far perfectly working) versions of LLVM (LLVM 3.6.2) could not be updated/recompiled for Sierra, are no longer allowed because (as far as I understand) of system, library and header changes and changed requirements since macOS Sierra. It seems like a circularity problem. Which could be cut through when either relaxing the testing lines in clamav's c++/configure and c++/configure.ac file or when not upgrading/using macOS Sierra or not using LLVM at all for clamav (I think, the latter would be a pity, because an external LLVM 3.6.x has worked very fine with clamav so far, at least at my installation).

(In reply to Sierk Bornemann from comment #6)
> If at least this restricting test to version < 3.7 namend above at these two
> lines in clamav's c++/configure (line 16611) and c++/configure.ac (line 99)
> file would not exist or conveniently could be made more relaxed, so that it
> wouldn't bother about a installed current stable LLVM 3.8 via MacPorts, that
> would be fine.

It's not nearly that simple.  The LLVM API changes incompatibly from one release to the next; therefore, the clamav code needs to be ported to each new version before the version constraints can be adjusted.

(In reply to Yaakov Selkowitz from comment #7)

> It's not nearly that simple.

That's what I assume. :)

> The LLVM API changes incompatibly from one release to the next
> therefore, the clamav code needs to be ported to each
> new version before the version constraints can be adjusted.

Hmmm, LLVM v3.7, v3.8 both have been long enough in development and beta stage..., haven't they?
clamav at least isn't compatible with LLVM 3.7.x, 3.6.x is the last version it functions with.

Release date version 3.6.0: 27 Feb 2015
Latest stable 3.6 (3.6.2) is of 16 Jul 2015

Release date version 3.7.0: 01 Sep 2015
Latest stable 3.7 (3.7.1) is of 05 Jan 2016

Release date version 3.8.0: 08 Mar 2016
Latest stable 3.8 (3.8.1) is of 11 Jul 2016

Latest version in development 3.9 (3.9.0) is since 2 Sep 2016.


I think, clamav gently really should catch up on this, shouldnt it? It gently is time, isn't it?

Reminder: meanwhile, LLVM is at version 5.0 (since 07 Sep 2017).

Any progress on this issue?

We are currently testing patches from Sebastian for LLVM through version 3.9. We hope to get these into 0.99.3.