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
Related
I'm looking for a cross compiler to compile for linux under the msys2 environment.
I'm looking for somethink like x86_64-w64-linux-gcc. But I can't find it.
Which package I have to install?
You'll need a VM or a Linux machine to test the resulting binaries, so I'd just compile on one in the first place.
But cross-compilation should be possible too:
Boot up your favorite Linux distribution in a VM.
Install the libraries you want to have. Install g++ to get libstdc++, and possibly other basic libraries.
Copy the root directory / from the VM to the Windows machine.
You only need headers and libraries, not everything. You'll have to experiment to know what directories can or can't be safely removed.
Install Clang on the Windows machine. Installing LLD is also a good idea (it's a separate package in MSYS2; or, if you're using the official Clang binaries, it's bundled with them).
We're using Clang, because it's inherently a cross-compiler, i.e. doesn't require separate binaries to target a different platform, unlike GCC.
Compile with Clang with --target=x86_64-pc-linux-gnu --sysroot=path/to/root/directory.
-fuse-ld=lld is probably a good idea as well.
The string x86_64-pc-linux-gnu was obtained by running clang++ --version on a Linux machine.
You might need a few more flags, but this should be a good starting point.
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).
According to the address-sanitizer home page it comes only with the gcc 4.8 or above. Isn't there anyway of using it with gcc 4.7?
No, there is no reliable way (to get ASAN before GCC 4.8). ASAN requires compiler support and is very intimately connected to your particular compiler (and version, and host and target systems, and specific configuration, etc...)
In other words, try to compile a recent GCC (that is, GCC 5.2 in july 2015; use that since ASAN did progress since 4.8 and you'll get more -fsanitize= options in recent versions of GCC) from its downloaded source code. See hints here & there. You should try some recent Linux distribution.
(on Linux or other POSIX systems, you don't need root privileges to configure, compile, and install gcc-mine-5 in $HOME/soft/; you need appropriate ../gcc-5.2/configure options, notably --prefix=$HOME/soft --program-suffix=-mine-5, then add $HOME/soft/bin/ in your PATH then run with CC=gcc-mine-5 e.g. for make)
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).
I've downloaded MinGW with mingw-get-inst, and now I've noticed that it cannot compile for x64.
So is there any 32-bit binary version of the MinGW compiler that can both compile for 32-bit Windows and also for 64-bit Windows?
I don't want a 64-bit version that can generate 32-bit code, since I want the compiler to also run on 32-bit Windows, and I'm only looking for precompiled binaries here, not source files, since I've spent countless hours compiling GCC and failing, and I've given up for a while. :(
AFAIK mingw targets either 32 bit windows or 64 bit windows, but not both, so you would need two installs. And the latter is still considered beta.
For you what you want is either mingw-w64-bin_i686-mingw or mingw-w64-bin_i686-cygwin if you want to compile for windows 64. For win32, just use what you get with mingw-get-inst.
See http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure for an explanation of file names.
I realize this is an old question. However it's linked to the many times the question has been repeated.
I have found, after lots of research that, by now, years later, both compilers are commonly installed by default when installing mingw from your repository (i.e. synaptic).
You can check and verify by running Linux's locate command:
$ locate -r "mingw32.*[cg]++$"
On my Ubuntu (13.10) install I have by default the following compilers to choose from... found by issuing the locate command.
/usr/bin/amd64-mingw32msvc-c++
/usr/bin/amd64-mingw32msvc-g++
/usr/bin/i586-mingw32msvc-c++
/usr/bin/i586-mingw32msvc-g++
/usr/bin/i686-w64-mingw32-c++
/usr/bin/i686-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-c++
/usr/bin/x86_64-w64-mingw32-g++
Finally, the least you'd have to do on many systems is run:
$ sudo apt-get install gcc-mingw32
I hope the many links to this page can spare a lot of programmers some search time.
for you situation, you can download multilib (include lib32 and lib64) version for Mingw64:
Multilib Toolchains(Targetting Win32 and Win64)
By default it is compiled for 64bit.You can add -m32 flag to compile for 32bit program.
But sadly,no gdb provided,you ought to add it manually.
Because according to mingw-64's todo list, gcc multilib version is done,but gdb
multilib version is still in progress,you could use it maybe in the future.
Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet -w64-mingw32.
gdb -- Native support is present, but some features like multi-arch support (debugging 32-bit and 64-bit by one gdb) are still missing features.
mingw-64-todo-list