Oh my... the build now takes ages and it's just that horrible I can't describe it :P.
Clamav upstream: "LLVM allows our analyst team to write advanced detection logic. Certain pieces of malware can't be detected by a simple hash. The analyst team writes bytecode signatures that safely run in our LLVM runtime. We bundle LLVM inside of ClamAV's source because we've made heavy modifications to make it safe for our use. We've removed a lot of instructions that could potentially harm machines in case a piece of malware is somehow able to explain a weakness inside of LLVM while ClamAV scans the sample. Due to the nature of our modifications, we can't simply submit patches upstream. We've essentially forked LLVM's source and included the fork within ClamAV's source code." Basically, they want people to use the bundled llvm version.
tbh I do not feel qualified to decide if we can / should make it use our system LLVM .. as eras posted they seem to have made quite a few modifications.. CC'ing 2nd llvm maintainer voyageur, mgorny: if you want to take this up feel free otherwise I will close this bug as WONTFIX/... at some point.
Hmm also they use a 2.9 or 3.0 build of llvm, with option for an external one, but it has evolved a bit since 3.0 (ignoring the local modifications they made). I am not sure unbundling is possible/doable without a feature/performance cost :/
Well I certainly don't have the time (nor am I qualified) for this.. Unless someone else (from the llvm team maybe) wants to have a go at this i will close this bug as UPSTREAM or WONTFIX in a while.
closing this as WONTFIX - at least clamav doesn't release new versions too often.
Created attachment 436194 [details, diff] clamav-dynamic-llvm.patch Adding a patch against 0.99.2 ebuild to enable using the system llvm as dynamic library. Not expecting this goes into the tree, but in case anyone wants to do this too. This helps getting back some memory from clamd, however has the drawback to not use the bundled, optimized (more secure?) llvm.
