We have a project that was working fine in Red Hat Enterprise Linux Server release 6.2. Since GCC version is getting updated periodically, we wanted to have our project to be independent of GCC upgrade in local system. Hence we wanted to keep GCC toolchain (binaries and libraries) in our project rather than standard location in the machine. ldd of our binaries generated out of our project should depend on the libraries in my our project not from the gcc libraries available in local system (because it might change at any time).
How do I do that? Where I shall get specific GCC toolchain for intel 64 bit (C & C++ compilers) ?
Current GCC Version: gcc-4.4.6-3.el6.x86_64
Related
I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).
First Question: What is the best way to support various 'standard' Linux platforms with a single C++11 binary?
This binary uses a handful of third party libraries including boost, zlib, xml2, openssl (all of which
I can build statically).
The binary must run on a variety of Linux platforms for x86_64: Ubuntu 16.04 and 14.04, Centos 7.2 and Debian.
Soon it must run on Darwin x86_64 and Ubuntu 16.04 on a Beagle Bone Black.
The default versions of compilers, libstdc++ and libc runtimes vary quite a bit on these platforms.
I have had some Linux success building on Ubuntu 14.04 with an upgraded (toolchain r-test) g++ 5.3 compiler
using these compiler options (note not using the "-static" switch):
-static-libstdc++ -static-libgcc -D_GLIBCXX_USE_CXX11_ABI=0
However, this requires installing the upgraded 5.3 compiler on the host (default is 4.9 IIRC) and
some runtime libs on the target platforms which is not preferred and risks issues with libc.so.
If it should be determined that this sort of solution is best, then I would prefer to build on
16.04 with the newest g++ or clang with switches so the binary runs on older platforms with
minimal changes to defaults. Yes, I know I am perhaps asking for the moon :)
Second question: instead of one binary, maybe one compiler and libc for all platforms including Darwin and Windows?
I was also considering an attempt to use musl to create a 'more consistently behaved binary. I could consider using clang instead of g++.
Anyone with experience/recommendations? I would very much like to avoid maintaining
separate compilations and combinations of third-party libs and compilers and settings and upgrades for each platform (especially for Linux targets but pretty typical for different operating systems).
Using the same version of the same compiler and possibly the same version of a libc would be best
but may not be possible: clang with musl?
Thanks
I'm on Mac OS X 10.9 Mavericks with command line tools installed, so I got clang-500.2.79. However, some software does not build with clang, hence I want to install GCC. So I got a question about GCC, specifically what will happen later when if I decide to upgrade GCC.
Suppose I install current version of GCC in /usr/gcc-4.8.2. Suppose I also use this gcc to build and install some software on my system that links against shared libraries in /usr/gcc-4.8.2/lib (in addition to system libraries in /usr/lib).
Suppose also I later decide to upgrade GCC to say version 4.9 and install it in /usr/gcc-4.9 and remove the old version in /usr/gcc-4.8.2.
Will the software that linked against shared libraries in /usr/gcc-4.8.2/lib continue to work i.e. will it magically (libtool?) find shared libraries in /usr/gcc-4.9 now? Or will everything I ever built with gcc-4.8.2 have to be recompiled after gcc upgrade?
I have started working on linux for about 6 months or so and now I
wanted to compile Linux version 2.6.39. Here are my questions for
the upgrade :
a. How will I get the GCC, Make, BinUtil and other tool dependency
of linux with their versions.
b. After compiling the tools how to make toolchain for linux
compilation.
I have searched various websites for this. I got information in bits and pieces and for specific linux versions. Is their a site or something where I can get all the information about the upcoming linux upgrades with the details.
My Current Linux machine details are :
Distro : CentOS 4.8
Linux version : 2.6.9
Gcc Version : 3.4.6
Binutils : 2.15.92
Make : 3.80
-Tommy
There are 2 options, depending on that type of kernel you want to build:
If you want a kernel for your machine (or a similar one), you can use the GCC that you already have from your distro.
If you want a kernel for another architecture (like ARM, MIPS, etc) you NEED a cross-compiler. You can build a cross-compiler (a whole toolchain, actually) using something like crosstool-ng.
With crosstool-ng you can also build yourself a toolchain for the first case. This tool take care of downloading the tarballs with the sources for GCC, Binutils, glibc, etc.
If you just want to upgrade the kernel on your machine, regardless of the version, the steps are mostly the same:
Get the source with
wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.9.tar.bz2 or something similar
extract them with tar xjvf linux-*.tar.bz2 and then exter that folder
make oldconfig or make menuconfig or even better make localmodconfig
make
make install as root
I am using Cent OS 5.
It has legacy package installed.
With what version of gcc should I compile ?
Does it really required to compile with old gcc version to support old linux os ?
if yes why ?
I'm going to start off by saying that the easiest way to get software builds that will work on CentOS 4, or even older, is to build the code on those target distributions, or ship your code with some scripts/tools to make it easy to recreate a build on that machine. If you've ever downloaded a source code release, and did the /.configure && make && make install steps, this is what I'm talking about.
Those source releases are built upon the GNU Autotools system, which gives you auto-configuration (it determines what can and can't be used on the target system) and generates a makefile to build with.
There are alternatives to the GNU Autotools system (which, frankly, I find a chore to learn and use), like cmake and scons. Here is a page (on scons) which compares the popular build tools:
http://www.scons.org/wiki/SconsVsOtherBuildTools
So what if you still want to build on your CentOS 5 machine for older CentOS installs?
Now for why you do need legacy libraries and compilers to build with, if you want to build on your CentOS 5 system:
So you have CentOS 5, which runs this toolchain:
gcc 4.1.2
glibc 2.5.x
libstdc++ 4.1.2
And CentOS 4, which runs this toolchain:
gcc 3.4.x
glibc 2.3.x
libstdc++ 3.4.x
The big problem is that if you were to just build C or C++ software with the standard CentOS 5 tools, they would be linked to the CentOS 5 C and C++ libraries (glibc, libstdc++, libgcc), and these libraries are not backward compatible with older releases. That is, software built for glibc 2.5.5 is in no way guaranteed to run with glibc 2.4, or even glibc 2.5.4 (though unless there are special circumstances, you would be able to run glibc 2.4-built software on glibc 2.5.x). You will also need to build the dependencies against the older library versions.
When you go even older, you will need to build a cross-compiler (look up crosstool) that will allow you to target builds for older systems, that will link to the older versions of libc and other dependencies built against that as well.
Is there something else besides building on the target and such?
You could static link all your dependencies into the binary, so you wouldn't have to worry about the dependencies and such. However, I have never done such a thing and I forget if there was some problem to linking glibc statically, or if I'm thinking of some other major library that posed issues with static linking (on a technical level).