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? 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.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
[email protected]
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