SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What are you talking? CONFIG_KCSAN is not enabled in testing/packages/linux-5.12.x. If you wanted to enable it, you would first need a newer compiler. (It seems to be for kernel hackers.)
I don't have CONFIG_KCSAN
Only :
Code:
CONFIG_HAVE_ARCH_KCSAN=y
Which is enabled by default in my own kernel config
Which is enabled by default in my own kernel config
Yes, those CONFIG_*ARCH* type lines mean that something is supported by the computer architecture. HAVE_ARCH_KCSAN selected by [y]: X86 [=y] && X86_64 [=y]. It means that X86_64 supports KCSAN. But CONFIG_KCSAN is not enabled. And it can't be enabled without a newer compiler:
Code:
Symbol: KCSAN [=n]
Type : bool
Defined at lib/Kconfig.kcsan:23
Prompt: KCSAN: dynamic data race detector
Depends on: HAVE_ARCH_KCSAN [=y] && HAVE_KCSAN_COMPILER [=n] && DEBUG
Location:
-> Kernel hacking
(1) -> Generic Kernel Debugging Instruments
Selects: STACKTRACE [=y]
Socket.c: loadable library and perl binaries are mismatched (got handshake key 0x8e80080, needed 0x8dc0080)
Oh dear...
and all this script does is
use Sys::Syslog;
use Mail::Sendmail;
(yes even rebooted) *sigh* glad it was my spare test box and nothing critical
Solved..... turns out there was another Socket.pm floating in the system, how it got there is anybodys guess, different path from old perl, who knows, deleted it and all is good again.
>...another Socket.pm floating in the system, how it got there is anybodys guess
Same problem, I found another perl installation in /usr/local. How it got there I'll never know.
Perl Upgrade and Amavisd users / others can disregard the noise
Quote:
Originally Posted by Nobby6
Solved..... turns out there was another Socket.pm floating in the system, how it got there is anybodys guess, different path from old perl, who knows, deleted it and all is good again.
Thought I'd share this after allowing the perl upgrade on one of my smtp servers, which uses amavisd.
If you only have one mail server and are in production, schedule this for early hours of a morning, it wont be a 5 minute fix, but if you're lucky enough like me to be running multiple behind load balancers, it wont be too much pain, only took me about 90 mins (but I was doing other things at same time)
Multiple warnings here if you are upgrading with this setup, so many things will fail due to mismatch modules
so if you are running amavisd you might be best to do this - it will solve most - but not all problems.
>...another Socket.pm floating in the system, how it got there is anybodys guess
Same problem, I found another perl installation in /usr/local. How it got there I'll never know.
yep
This is a clean install of current from oh last week in November last year... yep Nov 22 it was, new hardware, new everything, I always though cpan installed its stuff used /usr/local and has always been smart enough to know when a package already exists and tell you so.
perldoc perllocal reports all locally installed modules by cpan from memory, I guess i'll have to install a vanilla -current and see what it reports, no good now since i've updated all my machines
subversion should be recompiled against the new perl, I think?:
Code:
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Core/_Core.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Repos/_Repos.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Ra/_Ra.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Delta/_Delta.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Wc/_Wc.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Fs/_Fs.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Client/_Client.so
libperl.so => not found
subversion should be recompiled against the new perl, I think?:
Code:
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Core/_Core.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Repos/_Repos.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Ra/_Ra.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Delta/_Delta.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Wc/_Wc.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Fs/_Fs.so
libperl.so => not found
- /usr/lib64/perl5/vendor_perl/auto/SVN/_Client/_Client.so
libperl.so => not found
I ran an ldd on every .so inside /usr/lib64/perl5 (which made me caught a couple of obsolete packages I had installed fomr SBo and alienBOB):
Code:
for F in $(find /usr/lib64/perl5 -type f -name "*.so") ; do
echo -e "\n- ${F}"
slf ${F} | cut -d : -f 1 | grep ".*"
done
slf is part of slack-utils but you could use something like this instead:
Code:
grep ${F/\//} /var/lib/pkgtools/packages/*
Output from `svn --version --verbose`:
Code:
svn, version 1.14.1 (r1886195)
compiled May 21 2021, 16:48:59 on x86_64-slackware-linux-gnu
Copyright (C) 2021 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme
The following authentication credential caches are available:
* Gnome Keyring
* GPG-Agent
System information:
* running on x86_64-unknown-linux-gnu
- "Slackware 14.2 x86_64 (post 14.2 -current)" [Linux 5.10.39]
* linked dependencies:
- APR 1.7.0 (compiled with 1.7.0)
- APR-Util 1.6.1 (compiled with 1.6.1)
- Expat 2.4.1 (compiled with 2.3.0)
- SQLite 3.35.5 (compiled with 3.35.5)
- Utf8proc 2.6.1 (compiled with 2.6.1)
- ZLib 1.2.11 (compiled with 1.2.11)
- LZ4 1.9.3 (compiled with 1.9.3)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.