I'm compiling a piece of C-code that uses OpenMP with GCC 5.4 (Ubuntu 16.04). The compiled code works fine when executed on the same machine and the OpenMP parts also works fine.
The problem is that I want to move the compiled binaries to a Centos 6.5 machine. Currently I get an error which says:
/usr/lib64/libgomp.so.1: version 'GOMP_4.0' not found (required by ...)
I understand that GCC 5.4 (which I compile my code with) supports OpenMP 4.0 but is there a way to force GCC5.4 to compile my code to a target which dosen't forces the OpenMP 4.0 support? The CentOS machine includes GCC4.3 (and thus OpenMP 3.0). Or is there another solution to my problem?
Related
I tried almost a hundred things to make this works but nothing seems to be working.
I recently acquire a Mac book pro M1 MAX (so arm64 architecture), system provided by default with clang g++.
I wanted to install boost library. Using homebrew the 1.80 version was installed but I need to work on a project with the 1.65.1 version (I tried compiling my project with 1.80 version and tons of undefined symbols and errors were raised from boost library even if I have all of them, so I'm guessing I need to install the exact same version required)
so I decided to build and compile boost by myself following the boost guide
https://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html
Following section 5.1 I tried to use the bootstrap script and this one fails using Darwin toolset. (apparently some Clang warning caused error). I resolve then by changing the boost source code like this :
https://github.com/boostorg/build/commit/48e9017139dd94446633480661e5447c7e0d8b1b
But there's still lot of issues during the compilation
I don't know what to do to be able to compile with clang, I don't even know if this will be compiled for arm64 architecture.
anyway I install gcc compiler and tried with gcc toolset.
./bootstrap --with-toolset=gcc
The bootstraps works but then running the b2 script cause a segmentation fault instantly and on every commands I tried (even the --help options raised an exception...).
Why is building boost so complicated on arm chipset ?
What can I do to build boost (either clang or gcc, arm or cross compiled universal library) ?
I'm desperate at this point.
Thanks for the help.
I tried everything
with clang (darwin)
with gcc
with options to add arm64 as architecture
changing the source code of boost to fix
I'm trying to debug a segfault in some code built with mingw-w64's version of gcc. Since no Windows build of gcc includes the Address Sanitizer, I've been looking for a version prior to 4.9 that would allow me to use Mudflap instead.
(It has to be 4.8 or earlier, since Mudflap was removed from gcc in 4.9 - see https://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging)
I've tried using downloads of 4.8.1 and 4.6.4 from https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/ - but my builds all fail with cc1plus.exe: fatal error: mf-runtime.h: No such file or directory.
I have tried using the original MinGW as well, but 4.5 as downloaded from
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.5.0-1/
just fails silently with error code 1.
Is there any site that still hosts a mingw-w64 build of gcc old enough to include mudflap? Preferably with SEH threads instead of SJLJ. If not, is there anywhere I can download a mingw-w64-compatible set of libraries and headers to install mudflap to work with an existing build?
I'm trying to integrate Octave interpreter into my rigid body simulator compiled with GCC 4.8.1.
Following steps posted in the official documentation (https://www.gnu.org/software/octave/doc/interpreter/Standalone-Programs.html) allow me to compile, link, and successfully execute the first example. Note, that I can link the executable with both mkoctfile.exe, or g++ when minGW 4.8.1 is added to PATH.
However, the second example showing how to embed the interpreter into my program compiles, links, and then segfaults on execution when GCC 4.8.1 binaries are in PATH. It works, when I use the supplied compiler (in my case it's gcc 4.6.2 shipped with octave 3.6.1 on windows).
Do I need to build octave from source using GCC 4.8.1 in order to successfully link program compiled using that version, or is there any other way to do so?
Using GCC 4.6.2 is not an option for me, as my program uses c++11 features not present in that version.
I just learned that there is a newer Octave version available at http://mxeoctave.osuv.de/ which was compiled with GCC 4.9.2. This version of GCC works for me perfectly and the second example provided in the documentation started to work when compiled with g++ provided with the distribution.
This is a follow up Q to CUDA incompatible with my gcc version.
I've recently updated to Ubuntu 12.04 as well as grabbing the latest CUDA toolkit. My nvcc --version is showing: Cuda compilation tools, release 5.0 (My driver ver is 304.43.)
I'm trying to fix my build environment. I get errs about using GCC 4.6. I can probably fix this w/ the help of the above link. I'm wondering about the other 8 packages in this large project. Should I be concerned with building other pieces with one version of GCC-4.6 and my cuda stuff with GCC-4.5? I figure they should all be compatible, but I've never run into this before. Is this anything I need to be concerned with?
I have run into incompatibility issues with different versions of GCC.
Specifically, GCC 4.7 and 4.6. My Qt applications wouldn't compile for me, because I was using GCC 4.7, and the library was compiled against GCC 4.6. They compiled fine, and there seemed to be no problem at first. But then I ran into trouble actually running them.
I would recommend against using different versions of GCC in the same project.
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).