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