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.
Related
I am programming the Raspberry Pi Pico-W and I would like to link against the C++ STL, in order to use some of the Standard Library functionalities and containers.
I have found the package on Ubuntu, which I used in a professional development environment and I therefore also wanted to install it on Fedora 36, but found it missing in the official and unofficial repositories.
Following packages are available to me currently, so it is really just the libstdc++ that is missing, since the C Library (newlib) is there.
arm-none-eabi-binutils-cs.x86_64
arm-none-eabi-gcc-cs.x86_64
arm-none-eabi-gcc-cs-c++.x86_64
arm-none-eabi-newlib.noarch
libstdc++.i686
libstdc++.x86_64
libstdc++-devel.x86_64
One option I got recommended was to get the headers manually from arm itself, which also includes the rest of the toolchain.
Is there some package I am missing in the Fedora repositories, or is it just really not available as one package?
Fedora does not seem to provide such packages and I have also not been able to find copr repos for that.
Therefore the only solution left, was to install directly from arm.
This link gives a short guide for those that need it.
Additionally, since I am using NeoVim with its built-in lsp, I need to add a flag to the clangd configuration, namely --query-driver=/*/*/bin/*gcc, which globs for the compiler found in the compile commands. But this only as a side note.
After that everything seems to work as one would expect.
I have build servers that run Ubuntu 18.04 (in a Docker container), but I need to build binaries (various static and shared libraries and executables) for older versions of Ubuntu (e.g. 16.04), without having to install an older version of the OS.
Currently we use sysroot toolchains (that include compiler and libraries etc) and CMake toolchain files for building for other targets (e.g. ARM Poky/Yocto), and it would be ideal if we could use the same approach for building for older (or potentially newer) versions of Ubuntu.
Is it possible?
Anything is possible, but the easiest thing you can do is create a new Docker image (or some other type of machine) with an older OS on it. Then everything will "just work."
If you really don't want to do that, you need to identify all the dependencies, starting with libc, which have symbols missing on the older platform, then figure out how to avoid using those symbols. This will probably waste a ton of time, especially considering you already have one build container (making a second one shouldn't be hard).
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.
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.
I am new to both Qt and Linux C++ development (although I have many years C and C++ development experience on Windows).
I have some legacy C projects (source files and headers - [not using Qt]) that I want to compile into shared libs on Linux.
I am proposing to store my projects under the following structure:
/home/username/Projects/project_name
/home/username/Projects/project_name/src
/home/username/Projects/project_name/build
Can anyone tell me how to do the following (using Qt to simplify the build process)
Create different build configurations (debug, release etc)
Build a configuration to create the appropriate shared library
As an aside, I have only recently installed Ubuntu 9.10 and the only C/C++ development tool I have installed (using SPM) in Qt - so I dont know if I need to install some other GNU C++ tools.
BTW I have already checked and have gcc (v4.4.1) available on my machine. I do not appear to have g++ though - I do not know whether this is significant or not.
An Ubuntu system doesn't come with build tool chain by default. Instead it has a meta package that you will need to install:
sudo apt-get install build-essential
This will install, among other the g++ compiler, although I am not sure about the Qt headers an such. For them you will need the qt4-dev package (I assume you wish to work with qt4 rather then qt3).
As for the bould structure, you will want to consult the qmake manual, or you might want to consider using CMake (apt-get install cmake) instead. CMake allow for out of build sources, as you require, and personally, I can't recommend it enough.