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 -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ 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
