On July 29, 2021 5:50:26 AM EDT, Gene Heskett via clamav-users <clamav-users@lists.clamav.net> wrote:
On Thursday 29 July 2021 03:52:57 G.W. Haywood via clamav-users wrote:
Hi Gene,
On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:
On Wednesday 28 July 2021 14:24:46 G.W. Haywood via clamav-users wrote:
On Wed, 28 Jul 2021, Gene Heskett via clamav-users wrote:
/usr/bin/ld: cannot find -lpthreads
But pthread is installed. "sudo ldconfg -v|grep pthread" comes
back empty
Now what?
I'm guessing you have the stable version of ClamAV already
installed on the box, and so clamscan is installed? Assuming so,
please post the output of ...
ls -l `locate libpthread.so`
lrwxrwxrwx 1 root root 18 Feb 6 2019 /lib32/libpthread.so.0 ->
libpthread-2.24.so lrwxrwxrwx 1 root root 18 Feb 6 2019
/lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.24.so
-rw-r--r-- 1 root root 252 Feb 6 2019
/usr/lib/x86_64-linux-gnu/libpthread.so
ldconfig -p | grep pthread
libpthread_workqueue.so.0 (libc6,x86-64) =>
/usr/lib/x86_64-linux-gnu/libpthread_workqueue.so.0
libpthread_workqueue.so (libc6,x86-64) =>
/usr/lib/x86_64-linux-gnu/libpthread_workqueue.so libpthread.so.0
(libc6,x86-64, OS ABI: Linux 2.6.32) =>
/lib/x86_64-linux-gnu/libpthread.so.0 libpthread.so.0 (libc6, OS
ABI: Linux 2.6.32) => /lib32/libpthread.so.0
libevent_pthreads-2.0.so.5 (libc6,x86-64) =>
/usr/lib/x86_64-linux-gnu/libevent_pthreads-2.0.so.5
Ah. You have both 32 bit and 64 bit versions. That might be the
issue.
ldd `which clamscan` | grep pthread
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc1d4f17000)
The old version of clamscan is using the 64 bit version. Presumably
you're building the new version also to be 64 bit executables?
You may need to upgrade the library if the version of libpthread is
not accepted by the build, otherwise I guess you'll have to tell
the ClamAV build process where to find the shared object.
I may need some help on that. Can I assume its looking in
/usr/local, and not in /usr?
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?
I am involved with linuxcnc, and since IRQ latency is much better
with the 32 bit kernels, out of 6 machines here, 5 are running machinery
and are running older 32 bit kernels with the correspondingly smaller
stack frame that makes a context switch quite a bit faster.
I am getting setup to put a 64 bit bullseye on this box, but getting it all
together will be another week at least.
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.
synaptic isn't really advertising the 32 bit stuff, the only libpthread
that wasn't x86-64 was python-pthread, and nothing squawked when I removed it.
Now a rerun gets this:
gene@coyote:~/src/clamav-0.104.0-rc/build$ /usr/local/bin/cmake .. -D CMAKE_BUILD_TYPE="Release"
CMake Error at /usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Libcheck (missing: LIBCHECK_INCLUDE_DIR LIBCHECK_LIBRARY)
Call Stack (most recent call first):
/usr/local/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
cmake/FindLibcheck.cmake:89 (find_package_handle_standard_args)
CMakeLists.txt:192 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeOutput.log".
See also "/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeError.log".
Libcheck, its a perl thing that depends on libexporter which several
versions, not all of which are installed
CMakeError.log ends with this:
Linking C executable cmTC_38c19
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_38c19.dir/link.txt --verbose=1
/usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTC_38c19.dir/CheckFunctionExists.c.o -o cmTC_38c19 -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_38c19.dir/build.make:98: recipe for target 'cmTC_38c19' failed
make[1]: *** [cmTC_38c19] Error 1
make[1]: Leaving directory '/home/gene/src/clamav-0.104.0-rc/build/CMakeFiles/CMakeTmp'
Makefile:127: recipe for target 'cmTC_38c19/fast' failed
make: *** [cmTC_38c19/fast] Error 2
If you said its not ready for primetime, I'd have to agree. :o)
Cheers, Gene Heskett