I’m developing a cross-platform server software using C++14 and I want to be able to ship it as a binary to different versions of Windows and Linux. For Windows have I created a binary with all dependencies statically linked. I successfully been able to install and run this binary on all versions of Windows Server.
How can I generate a binary for Red Hat Enterprise Linux that can run on RHEL6.4 or later?
To get support for C++14 on Linux, it seems I would need to use version 5 or later of GCC? No version of Red Hat Enterprise Linux seems to be delivered with a GCC version that support C++14? If I have understood it correctly, I need to use Red Hat Developer Toolset 4.1.0 to get a GCC version that supports C++14?
Red Hat Developer Toolset 4.1.0 seems to only supports RHEL6.5 and later, but I can live with that. So if I use Red Hat Developer Toolset 4.1.0 and compile my software on RHEL6.5, how should I link it?
When reading the Developer Toolset 4.1.0 documentation it seems to exist an ABI compatibility issue and Red Hat recommends the use of -std=c++98 for production software development? Does this mean I can’t use C++14 and create a binary that can run on different Linux version, even within the same type of distribution?
Any help on clarifying this issue would be greatly appreciated.
I can tell you what is done for the product that I help develop.
We build our own versions of GCC and binutils on every UNIX/linux distribution that we are targeting for release, and build our sources with that. We also vendor in to our sources all C++ libraries on which we depend (like boost, etc.). Finally, we statically link libstdc++ from our custom toolchain.
The result is that we have binaries that only depend on the C interface associated with each specific linux distribution, which lets us use whatever version of the C++ standard that we want during development.
We then publish packages and binary tarballs for each distribution.
We also build a "generic" version (built, as always, with our custom toolchain) on a very old linux system, and with many features disabled so that we don't pick up dependencies on the required/supporting system libraries. That version depends on very few system libraries beyond libc and libpthread, so can be run on almost any linux distro that ships with the libc minimum.
Related
I'm relatively new to coding and building apps, and I wan to contribute to PowerPC Linux via packages. So I'm trying to port apps and tools over to then package them for the platform and try to package them for different distro's such as ubuntu and void. But, as it stands with running Ubuntu Mate 16.04, basically everything is out of date (LLVM, Clang, ETC) so I'm having to build stuff by hand to get other stuff built, which atm is Firefox 61.
No problem! But, what all tools should I acquire? And I have the system as up to date as I can make it by the way, the tools are just out of date. I have the code for LLVM, clang, and associated tools, but I don't know what other tools I may need in the future (If I have Clang do I need GCC? If an app calls for GCC in the build process can I bump it to clang instead? What tools do I need for python? Or rust? What are your general recommendations for languages I should be up to date with?).
For note, I'm building on-platform via a powerbook G4 A1138. Its a little slow, but its not that bad over all. I know I could cross compile, but something doesn't sound right about building on X86 for powerpc. Like I'm gimping the platform by doing that.
Anyways, all the info I can get would be helpful! Thanks!
There is a clang-5.0 and clang-6.0 for powerpc in the Ubuntu repository.
The PPA for Ubuntu Toolchain Uploads (restricted)” team has very recent toolchaing for powerpc on 16.04 too.
We have some servers with ARM CPU and will test some SW applications. With Ubuntu system, there is no big problem because the kernel and the SW are quite up-to-date. But with CentOS system, some tools and libs are quite old on ARM. For example, the GCC compiler is still 4.8.5 and some features couldn't be supported.
On X86_64, this is not a problem, because there are SCL and other sources with stable packages.
On ARM, now I find to choices, one is from RH and the other is from Linaro.
https://releases.linaro.org/components/toolchain/binaries/latest/
The Linaro project provide some source of GCC5, 6 and 7. We could build and run on the system. Ubuntu ARM version is using the GCC from Linaro right now. But on the release notes, it just mentions Ubuntu but no CentOS support. (Even this could be done on CentOS)
https://buildlogs.centos.org/centos/7/sclo/aarch64/rh/
The RH also provide the GCC for aarch64 as on the X86_64 computer/server. But now it is still in the test repository but not the official update sources. And only GCC6 and 7 are provided.
So any suggestion? Should I use the test version from centos.org or the source code from Linaro.
Many thanks in advance
Depending on the ARM CPU Servers are you targetting, the vendor may also provide you with the OS and packages/repo which is recommended to be used.
Linaro might be a better pick than the test repo (expected to be more stable) in the case that you are doing some functional/performance testing of SW applications. Even though centos7.4 is not stated as officially supported platforms, its worth a try. Its likely that the Linaro GCC toolchain will just work on the OS of your choice.
You may also download the latest GCC from the public mirrors and try, say one of the GCC 7 releases (At the moment, the latest is gcc 7.3.0 https://gcc.gnu.org/gcc-7/). Aarch64/Aarch32 are supported targets.
Whatever you chose, ARM CPU server ecosystem is actively evolving as these chips are just hitting the market. You might want to check which of the above (Linaro/GCC/RH) is being actively contributed to in the area of the target platform of your choice.
Background:
Im using QT and have visual studio 2012 as my IDE (used the QT plugin for visual studio).
And finally the whole project is done. However due to my .NET background I have no experience when it comes to deploying my project so it can be run on Linux.
Question:
Anyone knowing how to deploy a QT project made in visual studio to linux?
You should install Linux and prepare a Qt development environment on it.You can then copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
So don't think of cross compiling your app for Linux on Windows. From a complexity point of view, I think setting up a Linux machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards. After all you will need a real target environment to finally test your application.
Before you can deploy something you have to compile it for that platform, and here you have two main choiches: either you cross-compile which means you compile it on windows using a set of tools so that your software is built to run on a linux, or you get a linux machine, you copy your entire project over and let Qt for linux do the magic.
Once you have your working binary compiled on linux or for linux then you start thnking about deployoment.
If you really want to be fully linux-compatible and "linux-ally correct" you should distribute your source-code precooked using some tools like "automake" that will make it possible to linux users to compile it on any linux version.
If you do not want to release your source code, you technically can distribute binaries without source code (not sure if you will be ok with licenses) but you have to be aware that there is no standard in linux for distributing binary packages, there are at least 2 main package building standards that are the ubuntu/debian style and red hat (and friends) style.
You are going to find plenty of documentation about all this stuff from cross-compile to automake and of course building debian packages and building red hat rpm packages.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
I'd like to set up a cross-compilation environment on a Ubuntu 9.10 box. From the documents I've read so far (these ones, for example) this involves compiling the toolchain of the target platforms.
My question is: how do you determine the required version of each of the packages in the toolchain for a specific target platform? Is there any rule of thumb I can follow?
This is a list found in one of the websites linked above:
binutils-2.16.1.tar.bz2
linux-2.6.20.1.tar.bz2
glibc-2.5.tar.bz2
glibc-linuxthreads-2.5.tar.bz2
gcc-core-4.2.0.tar.bz2
gcc-g++-4.2.0.tar.bz2
But suppose I want to generate executables for standard Ubuntu 8.04 and CentOS 5.3 boxes. What are the necessary packages?
My primary need is to avoid errors like "/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found" in the customers' machines but in the future I want to deal with different architectures as well.
It is generally a good idea to build a cross-toolchain that uses the same version of libc (and other libraries) found on the target system. This is especially important in the case of libraries that use versioned symbols or you could wind up with errors like "/usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.11' not found".
Same Architecture
For generating executables for standard Ubuntu 8.04 and CentOS 5.3 systems, you could install the distributions in virtual machines and do the necessary compilation from within the virtual machine to guarantee the resulting binaries are compatible with the library versions from each distribution.
Another option would be to setup chroot build environments instead of virtual machines for the target distributions.
You could also build toolchains targeted at different environments (different library versions) and build under your Ubuntu 9.10 environment without using virtual machines or chroot environments. I have used Dan Kegel's crosstool for creating such cross-toolchains.
Different Architecture
As I noted in my answer to a another cross-compiler question, I used Dan Kegel's crosstool for creating my arm cross-toolchain.
It appears it may be slightly out of date, but there is a matrix of build results for various architectures to help determine a suitable combination of gcc, glibc, binutils, and linux kernel headers.
Required Package Versions
In my experience, there really isn't a rule of thumb. Not all combinations of gcc, binutils, glibc, and linux headers will build successfully. Even if the build completes, some level of testing is necessary to validate the build's success. This is sometimes done by compiling the Linux kernel with your new cross-toolchain. Depending on the target system and architecture, some patching of the source may be necessary to produce a successful build.
Since you are setting up this cross-compilation environment on Ubuntu 9.10, you might want to look into the dpkg-cross package.
Compiling for other Linux distributions is easiest by installing them in virtual machines (apt-get install kvm) and then doing the compilation from within. You can also script them to do it automatically. Building a cross-compiler and providing the exact same versions of all libraries and such, as the other Linux distro does, is nearly impossible.
My question is: how do you determine
the required version of each of the
packages in the toolchain for a
specific target platform?
...
binutils-2.16.1.tar.bz2
gcc-core-4.2.0.tar.bz2
gcc-g++-4.2.0.tar.bz2
Generally pick the latest stable: these only affect your local toolchain, not runtime.
linux-2.6.20.1.tar.bz2
You don't need this. (For targeting embedded platforms you might use it.)
glibc-2.5.tar.bz2
glibc-linuxthreads-2.5.tar.bz2
You don't need these. I.e. you should not download them or build them; you should link against the versions from the oldest distro you want to support.
Is there any
rule of thumb I can follow?
But suppose I want to generate
executables for standard Ubuntu 8.04
and CentOS 5.3 boxes. What are the
necessary packages?
You survey the distros you want to target, find the lowest common denominator versions of
of libc, libstdc++, pthreads, and any other shared library you will link with, then copy these libs and corresponding headers from the box that has these LCD versions to your toolchain.
[edit] I should clarify, you really want to get all the dependent libs from a single system. Picking and choosing the LCD of each file version from different distributions is a recipe for a quick trip to dependency hell.
Depending on your target platforms, have you considered using Optware?
I'm currently working on getting Mono and Moonlight built for my Palm Pre using the cross-compilation toolchain (and the Optware makefiles handle the majority of dependencies already).