I have glibc version 2.15 on my BeagleBone Black. I want version 2.19, but I don't know how to upgrade to the newest version. opkg list-upgradable doesn't print anything. What should I do?
root#am335x-evm:/lib# ls -la | grep libc
-rwxr-xr-x 1 root root 888940 May 2 2013 libc-2.15.so
lrwxrwxrwx 1 root root 12 Mar 31 02:33 libc.so.6 -> libc-2.15.so
I know this part is not an easy task but here are few methods to upgrade package on linux embedded device.
1) Method:
Download glibc-2.19 debian package on to device (either directly using curl or download onto PC and scp to the device)
(download the debian package based on your architecture type 32/64 bit)
Use Opkg module to install the new glibc package,
opkg -f /etc/opkg.conf -d ram update
opkg -f /etc/opkg.conf -d ram install <package-name>
Note:
a) verify the opkg configuration file
b) below is sample of config file
src/gz repo <package-repository-url>
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
arch all 100
arch armv7l 200
arch armel 300
2) Method:
If you have internet on beagle bone then refer below links and you can find some command format examples.
http://wiki.openwrt.org/doc/techref/opkg
http://wiki.blue-panel.com/index.php/OPKG_%28en%29
3) Method:
Download the package source files on to your linux PC and cross-compile to beagle bone.
And then scp all required files of the package(binary,config files.....)
Related
I am trying to figure out how to install python2 on centos9 stream. I am getting the errors below. Any suggestions?
sudo dnf install python2
Last metadata expiration check: 0:04:48 ago on Thu 24 Feb 2022 01:43:10 PM EST.
No match for argument: python2
Error: Unable to find a match: python2
how to install python2 on centos9 stream
You cannot do that from any repo. No available repo / no packages.
Reason: python2.7 had End Of Life two years ago.
Yes, you can, using this method:
If you cannot find a package for your distribution (and you probably should be able to), you can download a single-file executable "AppImage" containing Python 2.7 and the standard library. Just download the file, make it executable, rename it "python2" or create a symlink of that name pointing to the AppImage file, and put it in /usr/local/bin/, and getmail will happily run with it.
For example, on an x86_64 Linux system, you could:
wget https://github.com/niess/python-appimage/releases/download/python2.7/python2.7.18-cp27-cp27m-manylinux1_x86_64.AppImage
sudo install -m 755 python2.7.18-cp27-cp27m-manylinux1_x86_64.AppImage /usr/local/bin/
sudo ln -sr /usr/local/bin/python2.7.18-cp27-cp27m-manylinux1_x86_64.AppImage /usr/local/bin/python2
Source: https://pyropus.ca/software/getmail/documentation.html#python3
I have a CentOS 7 (EPEL-Repo is registered) but I do not find the package for CPP-REST (libcpprest-dev in Debian) in the repos.
Do I need to install it from vanilla or is there a package in CentOS?
Thanks!
Short answer...
There is not an "official" CentOS 7 package at this time (2018-10-03) for cpprestsdk (libcpprest-dev in Debian).
Long answer (sharing this in case it helps anyone)...
You could build cpprestsdk from source, but the instructions "How to build for Linux" (https://github.com/Microsoft/cpprestsdk/wiki/How-to-build-for-Linux) do not include CentOS or RHEL (at the time of this writing, 2018-10-03).
Before building cpprestsdk on CentOS 7, you'll need to update boost (at time of this writing CentOS 7 repos have boost 1.53, but 1.54 is required, and 1.68 is latest). You can do this to update (using boost 1.68 as example):
cd && wget https://dl.bintray.com/boostorg/release/1.68.0/source/boost_1_68_0.tar.gz
tar -xzvf boost_1_68_0.tar.gz
cd ~/boost_1_68_0
./bootstrap.sh --prefix=/opt/boost
sudo ./b2 install --prefix=/opt/boost --with=all
After updating boost, I was able to build cpprestsdk on CentOS 7 like this...
Install some needed tools/libraries:
sudo yum -y install git cmake3 openssl-devel gcc-c++ make
Download the cpprestsdk project:
git clone https://github.com/Microsoft/cpprestsdk.git casablanca
cpprestsdk wants to treat warnings as errors. I had to turn this off by commenting out this line in ~/casablanca/Release/CMakeLists.txt:
#set(WERROR ON CACHE BOOL "Treat Warnings as Errors.")
Prepare/build cpprestsdk project:
cd casablanca/Release
mkdir build.release && cd build.release
cmake3 .. -DCMAKE_BUILD_TYPE=Release -DBOOST_ROOT=/opt/boost
make
Install header files and library
sudo make install
Notice that I am calling cmake3 (not cmake) and I am specifying the boost root; which differs from the official instructions that appear to be written and tested for Ubuntu (not CentOS or RHEL). To build my projects using cpprestsdk, I had to use ldconfig to find the library paths.
I have forked and modified a minor thing from the official mongodb repository on stable branch 3.4.
I am building in a fresh VM installed from scratch with required packages to build the source.
Build instructions impose GCC 5.3 which is not available in the stable distribution of debian 8. If I switch to unstable and compile, (it works yay but) the output executable is >600MB and does not run on a stable debian that has GCC 4.9.
Question 1: how is it possible that my build is 10 times bigger in size than the version proposed in the mongodb debian 8 repository ?
-rwxr-xr-x 1 root root 52M Sep 11 17:50 /usr/bin/mongod
-rwxr-xr-x 1 root root 664M Oct 28 11:50 /build/mongod
Question 2: moreover, my built version cannot run on debian 8 stable becauses it uses GCC 5.3 which is not available in stable. So how can I build it such that it runs on the stable debian 8 just like the package repository that mongodb provides ?
If I try to build using GCC 4.9.2, despite some errors that I can eventually fix, it still is a hell to compile. Does that mean they have some magic tricks ?
# scons core -j 3 --ssl --link-model=object --opt=on --dbg=off --disable-minimum-compiler-version-enforcement --disable-warnings-as-errors
[...]
src/mongo/db/repl/storage_interface_mock.h:50: error: undefined reference to 'vtable for mongo::repl::CollectionBulkLoaderMock'
/usr/bin/ld.gold: the vtable symbol may be undefined because the class is missing its key function
I can see that there is a special directory debian in the source repository, could that maybe somehow could be used to build the debian package. How should I use it ? Would that make it run on debian 8 stable ?
Answer to Question 1: The executable output contains debug symbols that can be removed from the binary using the strip linux command. This reduces the file size back to ~50MB
Answer to Question 2: In order to build for Debian 8 stable, one should not use the GCC compiler but rather use CLANG. The documented minimum verson is 3.4 and version 3.5 is in the stable debian 8 packages.
There are some minor compilation issues though and issues in the Scons compile scripts (python). But after fixing those, it produces an executable able to run on debian 8 stable.
scons core -j 3 --ssl --link-model=object --opt=on --dbg=off --disable-minimum-compiler-version-enforcement --disable-warnings-as-errors CC=/usr/bin/clang CXX=/usr/bin/clang++
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.
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