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.
Related
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?
We need to find a cross-compilation toolchain for an ARM embedded linux target that satisfies the following criteria:
Kernel 3.17
GLIBC 2.18
Recent version of GCC is required to compile some third-party code
Those requirements brought me to generate a custom cross-compilation toolchain using crosstool-ng. I selected the min kernel version, min glibc version and it seemed to work well until I tried to compile code containing C++.
Because the new GCC is using a more recent libstdc++ than what is available on the target, the executable won't run and we get an error like this:
/usr/lib/libstdc++.so.6: version `CXXABI_1.3.9' not found
The code compiled fine with an older version of GCC.
Looking at the configuration options for crosstool-ng I didn't find anything that would let me change the min libstdc++ version, like for glibc.
Is there a way to target an older libstdc++ version without downgrading GCC?
Can I use the headers and libstdc++.so files from the target to replace the ones GCC is using when cross-compiling?
I have gcc 4.8.5 installed on a Red Hat 7.5 machine.
I wish to compile a software package on this machine.
In order to compile this package, I need to run "make".
However, when I run this, I see the following error message "error: ‘make_unique’ is not a member of ‘std’".
My understanding (possibly incorrect) is that this message originates from the fact that 4.8.5 uses C++11 and "make_unique" requires C++14. So I presume the way to compile this is to specify that C++14 should be used when I run "make".
How do I do this ?
I have tried to set the C++ to 14 as follows:
cmake -G "Unix Makefiles" -D CMAKE_CXX_STANDARD=14
And then I ran "make".
But this gave the same error message.
You are using compiler that does not support C++14. As stated in the documentation:
GCC supports the original ISO C++ standard (1998) and contains experimental support for the second ISO C++ standard (2011).
It is no surprise, since GCC 4.8 was originally released in 2013 so it would be weird if it implemented a standard introduced a year later.
To use C++14 or even C++17 you can compile it with RH Devtoolset 8. The built software would run on target OS w/o any additional effort due to the "nature" of DTS compiler: the symbols available in the OS-shipped libstdc++ gonna be resolved dynamically, while C++11 and above gonna be linked to you executable from the specially built static libstdc++.a provided by DTS.
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.
my custom built gcc 4.6.0, installed in my home directory, on ubuntu 10.04, links the system libstdc++ instead of the custom built one, most of the time (as evidenced by ldd). to be more puzzling, using this newly built gcc, custom compiled openmpi libraries are linked correctly, and this is the only software i have compiled that behaves ok. does anybody have any explanation for this, or a workaround?
thanks
Isn't there an option to statically link the libstdc into the gcc when you configure it? --disable-shared if I understand how it works correctly. Worst case make another compile of gcc with that switch and see if you run into the issue.
I don't know why this isn't detailed more clearly on the GCC website for end-users. The GCC FAQ clearly states this is a common problem wrt libstdc++. Environment variables are troublesome. Wrapping the linker, nobody knows how to do that. Editing /etc/ld.so.conf isn't an option. Adding -Wl,-rpath everywhere, come on. The easiest solution is the specs file. For a typical 64-bit x86 Linux system, go into your custom gcc installation, in dirname `g++ -print-libgcc-file-name`and then run g++ -dumpspecs > specs. Edit that file, find the *link_command: section. After %(link_libgcc) add -rpath /home/user/bin/gcc-9/lib64 (of course use your own path). Or add the same rpath to end of *link: section. Alternatively, configure gcc with --with-specs='%{!static:%x{-rpath=/home/user/bin/gcc9/lib64} %x{-enable-new-dtags}}' . Enjoy your own C++ compiler that generates binaries that just work.
See also:
GCC specs file: how to get the installation path
Linking g++ 4.8 to libstdc++
How to configure libstdc++ with GCC 4.8?