[Pkg-clamav-devel] package status for jessie

[Andreas Cadhalpun]

Hi Sebastian,

On 23.08.2014 20:58, Sebastian Andrzej Siewior wrote:
> On Sat, Aug 23, 2014 at 05:07:48PM +0200, Andreas Cadhalpun wrote:
>>>> Perhaps it would be better to use ftruncate64.
>>>
>>> Yes, but this is nothing you should specify. The define should do it. So just
>>> digged a little into it.
>>
>> We could define it:
>> #define ftruncate ftruncate64
>
> no, since it wouldn't help.

Indeed, because the problem is in LLVM's static libraries.

>>> I've been looking where that truncate() user is coming from and I did not find
>>> a single user in the source.
>>
>> Did you use codesearch? It finds 4 uses of ftruncate [1].
>
> I search for truncate() not for ftruncate() exactly for that reason (because
> there are ftruncate() users in tree).

Sorry, I confused truncate and ftruncate.

>>> Anyway, it looks like we linking llvm staticly instead of using the external
>>> library. This isn't on purpose right?
>>
>> I think it is on purpose, because clamav upstream didn't want to ship shared
>> LLVM libraries...
> This makes sense as long as you use the in-tree llvm code.
>
>> But for Debian it would be better, if it was dynamically linked. (Otherwise
>> we don't benefit from bug fixes in LLVM minor versions without recompiling
>> clamav.)
>
> Good. So I guess that there is a -static switch which we are getting rid of.
> Otherwise I can't explain it :)

Unfortunately, it is not only a superfluous '-static'.
As far as I can tell, llvm only ships the static libraries!
Looking at the file list of llvm-3.4-dev [1], only one static library, 
libLTO.a, has a corresponding .so symlink.

Unless I'm missing something, linking statically against LLVM is the 
only option.

Therefore I think we must add a Built-Using field [2] containing the 
corresponding LLVM version.

Looking at LLVM's build log [3] one finds many uses of 
'-D_FILE_OFFSET_BITS=64', but it seems there is some problem in LLVM's 
build system, because not everything is built with that.

After adding '-D_FILE_OFFSET_BITS=64' to CXXFLAGS in LLVM's 
debian/rules, rebuilding LLVM and then rebuilding clamav against this 
LLVM, libclamav doesn't contain any non-LFS symbols anymore.

So I opened a bug against LLVM [4].

> Do you know by any chance what is the progress by upstream using external llvm?

I'm afraid I don't have any news about that. FWIW, the upstream bug [5] 
says the target milestone is 0.98.6.

Best regards,
Andreas


1: https://packages.debian.org/sid/amd64/llvm-3.4-dev/filelist
2: 
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using
3: 
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.4&arch=i386&ver=1%3A3.4.2-8&stamp=1408438465
4: https://bugs.debian.org/759162
5: https://bugzilla.clamav.net/show_bug.cgi?id=10981