I am attempting to install an RPM in my VM, and I am getting the following messages during yum install.
file /usr/lib64/libstdc++.so.6 from install of myPackage.x86_64 conflicts with file from package libstdc++-4.8.5-16.el7_4.2.x86_64
file /usr/lib64/libz.so.1 from install of myPackage.x86_64 conflicts with file from package zlib-1.2.7-17.el7.x86_64
file /usr/lib64/libgcc_s.so.1 from install of myPackage.x86_64 conflicts with file from package libgcc-4.8.5-16.el7_4.2.x86_64
file /usr/lib64/libgomp.so.1 from install of myPackage.x86_64 conflicts with file from package libgomp-4.8.5-16.el7_4.2.x86_64
file /usr/lib64/libgomp.so.1.0.0 from install of myPackage.x86_64 conflicts with file from package libgomp-4.8.5-16.el7_4.2.x86_64
I am running in Centos7, and I am pretty sure that the libstdc++-4.8.5-16 is coming in since I installed gdb (I am installing a set of pre-packaged RPMS) from the Centos repos.
Is there a way to resolve these conflicts? Is there a way to tell gdb, for example, to use the more up-to-date libstdc++ library?
Whatever mystery package you are attempting to install is badly behaved. It is trying to install some shared library files that, by rights, are "owned" by the libstdc++ package on CentOS 7. Yum is correctly rejecting the mystery package due to this misbehaviour.
You should talk to the package author and inform them that their package does not meet quality guidelines. If they are writing software that definitely, absolutely needs a newer version of libstdc++ than is officially distributed in this environment, then they could:
Use devtoolset, or
statically link the runtime,
or
package the newer shared library but install it somewhere isolated, at a location that will only be used by the mystery software. It must not take over from the platform's own packages unless you want it to cause weird runtime behaviours as every other C++ application on the system suddenly links with some mystery newer version of the GCC runtime library.
If different shared library versions are not required, then instead the author should:
build against the officially distributed libraries in the first place, and
denote prerequisites in their RPM's .spec file... to, e.g. libstdc++ & libgomp.
Related
I'm new to Linux, but I'm trying to distribute an application in .deb and .rpm format. I'm having trouble with the below three libicu libraries:
libicui18n.so.52.1 => not found
libicuuc.so.52.1 => not found
libicudata.so.52.1 => not found
The problem is that the version required for the application does not always match the version installed on the system, for example Fedora 26 comes with libicu 57.1 while my application is looking for 52.1. Adding libicu to the package dependency list doest help, because libicu is already installed, so installing libicu just gives:
Package libicu-57.1-6.fc26.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
I couldn't find a package for libicu52.1, but trying to install an older package doesn't seem to work anyway. I tried libicu-54.1-4.fc22.x86_64 but it says no package available, presumably because it's only available on Fedora 22.
I was thinking of including the libraries in the application package and having them install to /usr/lib64, but being a Linux newbie I'm unsure if this is an acceptable thing to do.
What's the best way to solve this?
Edit: I saw this post in the related section which says:
Newer versions of libraries should not break existing apps unless
you're using deprecated features.
I'm testing on Fedora 26 which comes with libicu 57.1. My application only requires libicu 52.1, so if the above is true I assume it should be working. Is there something I need to do to make it work?
Having your package install "extra" versions of libicu to /usr/lib64 would be very surprising to most users. Don't do that.
The standard practice here is to build different .deb and .rpm files per target platform. The same as you need to build separately for 32-bit vs 64, you need to build separately for, say, CentOS 6 vs 7. You can do this by running a set of virtual machines to do the release builds--one for each target platform you want to support.
If you truly need to make a single .deb or .rpm that works on many platforms, one way is to eliminate some of your dependencies. In this case, all those libraries are part of the same project (ICU), so if you don't really need to depend on that project, don't.
I was looking at the list of naclports for ported libraries and I want to use openssl for my native client extention. I can't find a proper instruction set to install these ported libraries, I downloaded the openssl compressed file and followed the instructions given in INSTALL file but that encountered some errors which I can't resolve.
To install a library ported to Native Client as part of naclports you'll need to:
Download and install the NaCl SDK:
https://developer.chrome.com/native-client/sdk/download
Set NACL_SDK_ROOT in your environment to point at the pepper_* version under the location you install it at.
You may want to explicitly install the very latest version: pepper_canary, with: ./naclsdk install pepper_canary
Sync the naclports repository: Checkout guide
Check out a branch that matches you SDK, or master for pepper_canary
To build openssl, do something like this:
./bin/naclports --force --from-source install openssl
If you have no local modifications you can drop the --force and --from-source flags
This will build the newlib NaCl version by default.
You can set TOOLCHAIN in the environment to: glibc / pnacl / newlib to select an explicit version.
The library will then be installed into your SDK.
On Ubuntu there is a command to install boost libraries which is something like this:
sudo apt-get install libboost-all-dev
does this command also install and compile the header-only libraries?
If not, what other terminal command would I need to execute so that I can install the FULL set of boost libraries?
My ultimate aim is to know which linux terminal commands I need to install (and have available) to obtain all of the boost libraries.
As is implied by "header only", one does not need to compile the header-only libraries. They're just headers.
Now, the libbost-all-dev package does install those libraries which need compilation (in addition to the header-only libs), but it does not compile them on the spot. Ubuntu is a so-called binary distribution, which means that it distributes packages in compiled form. Apt downloads the binaries and installs them immediately. This is in contrast to e.g. Gentoo which is a source distribution (and compiles everything on your machine).
In short, no further commands are necessary. Installing libbost-all-dev will install all available Boost libraries on Ubuntu.
Your questions, as posed, makes no sense.
The Debian / Ubuntu package libboost-all-dev has dependencies, and those dependencies do include the few binary library packages (eg Boost Thread, the formatting parts of Boost DateTime, etc pp). All those will get installed.
And yes, the intent of this meta package is to install the rest of the Boost development environment.
But it does not compile anything. All Debian / Ubuntu packages are pre-generated and built-offline and "just installed" at your end.
You can inspect the content of a package by browsing the online database.
But if you are only interested in header-only libraries I suggest to download the latest version of the boost libraries right from the official website; you should also learn how to build boost from the source because it's a know-how that you are very likely to use in a near future if you are relying on that library.
An equivalent step to browsing the online database, it's about using the following command
apt-cache show <package>
so, in your case
apt-cache show libboost-all-dev
and this will give you a very specific idea about what you are about to install.
I have openssl 0.9.8g installed on my computer...
It seems that it has a known bug which I ran into.
I wanted to install the current version 1.0.0d which seems to have fixed the bug.
so, basic install :
$ ./config
$ make
$ sudo make install
However even after recompiled my software I still get the same error, and it is for sure coming from 0.9.8 since it is written in the error :
error:1408F06B:SSL
routines:SSL3_GET_RECORD:bad
decompression:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s3_pkt.c:438:
Let's assume you installed your downloaded version of OpenSSL to /home/yourname/openssl. Then you need to tell your software to use that custom install instead of the pre-packaged 0.9.8 that already resides on your file system. There's no need to uninstall that, you can have several installations on your machine. "Telling" your software where to find your custom installation is by providing the linker with the correct paths where to find libssl and libcrypto. Add these to the linking options in your Makefile:
-L/home/yourname/openssl/lib -Wl,-R/home/yourname/openssl/lib
Then it should link against the new version just fine. To verify it did, you can use
ldd <your_executable_or_library>
and verify that the custom OpenSSL path is listed there and not the old one.
I'm not sure about the OS you are using, but my guess is that you first have to remove the erroneous old version before you move on the install the newer one. Some OSes don't put libraries installed with sudo make install in the same place as with a packet manager. Also the lookup order of the libraries might cause it to load the older one.
So for example I am creating some app that uses boost or openCV and on my developer machine all that is installed so app compiles without any problem. But I wonder how to make app tell OS to download libs I use on first run? Is it possible? (sorry - I am linux noob)
This is what package managers are for. What you do is you compile your project, and then you build a package (e.g. .deb or .rpm), using the appropriate tools. While doing so, you can specify where the various files in your package should go, but also which other packages your package relies on. These are known as "dependencies", and package managers like apt and rpm are pretty good at resolving them.
Here's the official debian guide to making packages to give you an idea:
http://www.debian.org/doc/maint-guide/
Alternatively, you can just distribute your program as-is and list the dependencies in the install instructions; users will then have to manually install them through their package manager before running your program.