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
_______________________________________________
Pkg-clamav-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
