I've trying to build some c++ libraries on a virtual Centos 7 distribution.
For a reason that I haven't found out this os can't see the /usr/local/lib or /usr/local/lib64 where these libraries are installed as other linux distributions do. So I had to add these folders on /etc/ld.so.conf. Then the c++ linker was able to see these libraries.
However when afterwards I gave
sudo yum update
I got the following message:
/usr/lib64/python2.7/site-packages/pycurl.so: undefined symbol: CRYPTO_num_locks
After searching I found that it was cause due to the existence of two version of libcurl. I gave
ldconfig -v | grep libcurl
And I got the following :
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
libcurl.so.4 -> libcurl.so.4.4.0
libcurl.so.4 -> libcurl.so.4.3.0
Meaning that I installed a new version of libcurl and now two versions coexist.
When I removed the folder paths from the /etc/ld.so.conf then yum worked fine but c++ linker could not find the c++ libaries that my app needs. I also tried to update the LD_LIBRARY_PATH but I had the same problems.
Is there a way to fix this issue without having reinstall the libraries on new location ? Is it safe to remove the older version?
The ls -lsa /usr/lib64/*curl* gave
0 lrwxrwxrwx. 1 root root 16 Aug 10 10:19 /usr/lib64/libcurl.so.4 -> libcurl.so.4.3.0
428 -rwxr-xr-x. 1 root root 435120 Nov 14 2016 /usr/lib64/libcurl.so.4.3.0
I tried giving
sudo unlink /usr/lib64/libcurl.so.4
sudo ln -s /usr/local/lib/libcurl.so.4.4.0 /usr/lib64/libcurl.so.4
I even gave them as root but every time I give ldconfig I get
libcurl.so.4 -> libcurl.so.4.3.0
while before ldconfig gives
libcurl.so.4 -> /usr/local/lib/libcurl.so.4.4.0
I had this same issue, but I didn't have two versions of curl or pycurl installed on my system. One of my end user software installs, changed the LD_LIBRARY_PATH and it didn't include /usr/lib or /usr/lib64. I tried adding them at the end of the path and I still received the same error. I added them to the front, and no more error. I have to inquire with my end user if there's a legitimate reason they excluded the default libraries from the enviroment variable.
The default path for standard libraries, as far as I know, on CentOS is /usr/lib and /usr/lib64. If you compiling from source, without explicitly specify the library path when you use ./configure, those libraries will be installed by default in /usr/local/lib or /usr/local/lib64 (usually lib64 is found on 64 bit OS). So if the libraries are installed there, you should add those path in /etc/ld.so.conf and run a ldconfig afterwards;
According to your example:
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
libcurl.so.4 -> libcurl.so.4.4.0
libcurl.so.4 -> libcurl.so.4.3.0
libcurl.so.4 is linked to 2 different library versions and I think that's the cause of your issue.
You could remove the second link, libcurl.so.4 -> libcurl.so.4.3.0, leaving libcurl.so.4 only linked to libcurl.so.4.4.0, run ldconfig and try again.
Related
I'm trying to install Net::SSLeay with Carton.
The installation fails with this message
Configuring Net-SSLeay-1.90 Running Makefile.PL Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n] n
*** Found LibreSSL-2.8.3 installed in /usr
*** Be sure to use the same compiler and options to compile your OpenSSL, perl, and Net::SSLeay. Mixing and matching compilers is not supported.
Checking if your kit is complete... Looks good
WARNING: /opt/homebrew/Cellar/perl/5.32.1_1/bin/perl is loading libcrypto in an unsafe way -> N/A
I've tried this with system perl, brew perl and multiple perlbrew perls.
Google came up with a temp solution to build homebrew using x86_64 architecture.
This did work for the libcrypto error, but gave me a whole different set of issues including mysql not running anymore.
Other "solutions" that I've tried are symlinking libssl & libcrypto as suggested by numerous other posts, all sadly without success.
Any ideas how to fix this or work around this without having to reinstall all brew packages as x86_64 ?
Quick Workaround
If you are looking for a quick workaround follow these steps.
Run carton bundle to create a vendor cache directory.
Go to cached tarball 'cache/authors/id/C/CH/CHRISN/' and unpack tar -xvzf Net-SSLeay-1.90.tar.gz
Edit Makefile.PL, change my $prefix = find_openssl_prefix(); to
my $prefix = '/opt/homebrew/opt/openssl#1.1'; ** adjust to your openssl location.
Save and create new tarball tar -czvf Net-SSLeay-1.90.tar.gz Net-SSLeay-1.90
Run carton install --cached to use the altered version
Hope this helps anyone in search of workaround
You can solve this in two steps:
upgrade ExtUtils::MakeMaker to at least version 7.58 (e.g. cpanm ExtUtils::MakeMaker)
install openssl via macports (sudo port install openssl) or homebrew (brew install --cask openssl)
After the Monterey update this broke again also on the x86_64 architecture, but just symlinking your latest openssl (where ever it is, depending how you have installed it) seemed to fix this. Example:
$ export OPENSSL_PREFIX=[find your openssl installation]
$ sudo ln -s $OPENSSL_PREFIX/lib/libssl.dylib /usr/local/lib/
$ sudo ln -s $OPENSSL_PREFIX/lib/libcrypto.dylib /usr/local/lib/
Better workaround:
I entered export OPENSSL_PREFIX=/opt/homebrew/opt/openssl#1.1 in my shell and then ran cpan. I checked the code in Makefile.PL and the first thing the function find_openssl_prefix does is to check the OPENSSL_PREFIX environment variable. If it is set, then it the function will return its contents.
Add the variable to your .profile, .cshrc, .bashrc, .zshrc, or whatever rc file your shell uses and you never have to worry about it again!!
As the title says, the library libpq.so is not in the path given by pg_config --libdir. I install postgresql posqtgresql-devel which provides the package libpq5 which in turn installs the libpq.so.
$ pg_config --libdir
/usr/lib/postgresql10/lib64
$ find /usr/ -name libpq.so
/usr/lib64/libpq.so
Our applications rely on the path given by pg_config --libdir to look for libpq.so but it fails. Is this some problem with OpenSUSE package management or is it that we shouldn't be using pg_config for this purpose?
pg_config provides information about how PostgreSQL was built.
It is usually used to build server extensions, but it should also work with client code like you are trying to do.
Since your PostgreSQL is installed in a path that contains the version, but your libpq.so is not, I'd assume that the latter is a symbolic link rather than being part of the installation package.
If there is no libpq.so in your PostgreSQL lib directory, I'd call that a packaging error. You should discuss that with the packagers.
I am trying to compile matconvnet-1.0-beta20 with Matlab 2016a on Ubuntu 16.04. Initial phase of compilation works fine:
untar('http://www.vlfeat.org/matconvnet/download/matconvnet-1.0-beta20.tar.gz') ;
cd matconvnet-1.0-beta20
run matlab/vl_compilenn
The error happens when I run vl_simplenn(network, image) which gives following error:
Invalid MEX-file '/home/matconvnet-1.0-beta20/matlab/mex/vl_nnconv.mexa64':
/usr/local/MATLAB/R2016a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version
`GLIBCXX_3.4.21' not found (required by /home/matconvnet-1.0-beta20/matlab/mex/vl_nnconv.mexa64)
To understand the cause of problem, I run /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC which doesn't give any output bash: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: Permission denied
Also more /usr/lib/x86_64-linux-gnu/libstdc++.so.6 gives no output:
******** /usr/lib/x86_64-linux-gnu/libstdc++.so.6: Not a text file ********
I did some research and found some possible solutions:
http://it.mathworks.com/matlabcentral/newsreader/view_thread/162466
The problem is that MATLAB secretly changes LD_LIBRARY_PATH on startup
to point to the MATLAB version of GLIBC++, so that GLIBC++ 3.4.9 can
no longer be found. The solution is to modify matlab/bin/.matlab7rc.sh
so that "LDPATH_PREFIX" contains the path to the version of GLIB
installed with your compiler, then this is found before the
matlab-supplied library.
so I edited /usr/local/MATLAB/R2016a/bin/.matlab7rc.sh and modified LDPATH_PREFIX='' in 195th line to LDPATH_PREFIX='/usr/lib/x86_64-linux-gnu'.
After applying this change, the problem still exist.
As suggested here, I copied .matlab7rc.sh to current working directory of project, but still error persist.
https://askubuntu.com/questions/719028/version-glibcxx-3-4-21-not-found
According to first answer, running this command
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 usr/local/MATLAB/R2014a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6
gives an error:
ln: failed to create symbolic link 'usr/local/MATLAB/R2014a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6': No such file or directory
Seems like second solution suggests changes of LD_PRELOAD path in .matlab7rc.sh, but it is not anywhere inside the file.
How to tell mex to link with the libstdc++.so.6 in /usr/lib instead of the one in the MATLAB directory?
From Matlab directory in /usr/local/MATLAB/R2016a/bin$ I run
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/libstdc++.so.6
but the problem still exist.
Maybe there I didn't apply the solution in the correct way Or maybe there is another solution elsewhere that I didn't find. Please let me know, I am very confused!!!
You need before execute (matlab in my case) add path of library:
In console execute this:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 matlab
I had the same problem.
In my case, to solve it, I first ran "locate" to list all the possible versions of the library in the system.
locate libstdc++
As an example, I report the result on my system
I then set the most recent version of "lib" by exporting the environment variable:
export LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21"
So, the fullpath of the library to be set depends on where it is allocated in your system.
There are 2 possible solutions:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/libstdc++.so.6
Install this package:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
MAYBE the second solution you mentioned really works, but you have done it before. So you cannot operate in the same way again because you have ever linked /usr/lib/x86_64-linux-gnu/libstdc++.so.6 to usr/local/MATLAB/R2014a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6. TRY rebooting?
Also, you use MATLAB R2016a, but this command applies to R2014a. Was it that you ignore this point?
Yum suddenly start to give the error pasted bellow
I tried to rebuild yum, but the error remains. I re-installed krb5-libs, but the error remains
How can I repair yum without reinstating Centos?
Error:
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/lib64/libkrb5.so.3: symbol krb5int_push_fscreatecon_for, version krb5support_0_MIT not defined in file libkrb5support.so.0 with link time reference
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.6 (r266:84292, Jul 10 2013, 22:48:45)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
At my machine the issue was caused by a second libkrb5support.so distributed with PostgreSQL 5.2 / PSqlODBC. After commenting the library path in /etc/ld.so.conf.d/psqlODBC.conf and runing ldconfig -v, I can run yum again without any issue.
In my case, the path to the "wrong" library is /opt/PostgreSQL/9.2/lib/libkrb5support.so.0
Edgar.
I encountered this error after defining LD_LIBRARY_PATH environment variable. It was fixed by adding /lib and /lib64 to LD_LIBRARY_PATH.
export LD_LIBRARY_PATH=/lib:/lib64:....
Run the below command to test what all the libraries you have:
# ldd /lib64/libkrb5.so.3
And make sure that the module 'libkrb5support.so.0' is available under '/lib64' directory or having the soft ink to the files that is inside /lib64 directory. If its not there then this error is expected. So manually you have to link it again.
From my test system:
# locate libkrb5support.so.0
/lib64/libkrb5support.so.0
# ls -l /lib64/libkrb5support.so.0
lrwxrwxrwx. 1 root root 21 Aug 19 15:52 /lib64/libkrb5support.so.0 -> libkrb5support.so.0.1
# ls -l /lib64/libkrb5support.so.0.1
-rwxr-xr-x. 1 root root 46336 May 1 2012 /lib64/libkrb5support.so.0.1
When I try to install any package such as php5, it gives me this error.
I did update and upgrade all libraries.
root#host:~# apt-get install apache2-mpm-prefork libapache2-mod-php5
Reading package lists... Done
Building dependency tree
Reading state information... Done
apache2-mpm-prefork is already the newest version.
The following extra packages will be installed:
libonig2 libqdbm14 php5-cli php5-common
Suggested packages:
php-pear
The following NEW packages will be installed:
libapache2-mod-php5 libonig2 libqdbm14 php5-cli php5-common
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/6,106 kB of archives.
After this operation, 18.7 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
debconf: delaying package configuration, since apt-utils is not installed
dpkg: warning: 'find' not found in PATH or not executable
dpkg: error: 1 expected program not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)
Can someone help me?
There is probably something messed up with the permissions of find, find on your installation is probably located in /usr/bin/find, to check the permissions of this application run
ls -l /usr/bin/find
This should return something like this:
-rwxr-xr-x 1 root root 136152 Oct 26 2010 /usr/bin/find
If this returns an error, try to ls find on other locations in you path (eg. /bin/find, /usr/local/sbin/find)
The first part should be identical for the command to work. If not, reset the permissions to with the following command:
chmod 755 /usr/bin/find
This should fix it.