On Thu, 29 Jul 2021 08:52:57 +0100 (BST) "G.W. Haywood via clamav-users" <clamav-users@lists.clamav.net> wrote:
> Maybe there's no need to worry about that. I've seen cases where the > build process looks for a shared object, finds a 32 bit version when > it's building for 64 bit, and then complains that it doesn't exist. > It does exist, but it's found the one for the wrong architecture and > doesn't understand what it's found. If this is the case here, it's a > little disappointing (after the build-up we've had for cmake) that it > will get it as badly around its neck as autotools. > > Do you really need the 32-bit stuff? Do you have mixed 32 bit and 64 > bit binaries on your system? If so you're going to run into this kind > of thing more or less randomly when you build anything and you might > need to dig into it yourself a bit more. If you don't need the mixed > architectures you'd be better off without the 32 bit stuff in there. > > You could try using the package manage to try to remove the 32 bit > version of libpthread. If it's needed by something it will tell you, > and you can take a view on what to do abuot it. ================================= Are the build tools that deficient? I have both 64 and 32-bit stuff on my Debian system, and the 'file' command is able to report what a shared object file is (e.g., see below). Maybe CMAKE does it better? /usr/lib/x86_64-linux-gnu/libasan.so.5.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3cf2e4b5261216f9a156ed5dc2953d8b6f98987d, stripped /usr/libx32/libasan.so.5.0.0: ELF 32-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1289f4162c3de1fbe87d1f28ee3876ec8467ac2d, stripped _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
