I have a program that is build with a different version of the GCC than the one on the system. When I try to debug the program using GDB, I am getting errors like
libstdc++.so.6: version `GLIBCXX_3.4.20' not found
libstdc++.so.6: version `CXXABI_1.3.8' not found
libstdc++.so.6: version `GLIBCXX_3.4.21' not found
But when I build and run the executable, I get no errors.
It seems that GDB is using a different libstdc++ than the one used when building. Is there a possibility to tell GDB what libs to use ?
At build, using Makefile, there are some variables set that say what g++ to use, so it will be not the one on the system
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?
I'm trying to see if it's possible to use a gcc plugin in an ARM cross compiler (arm-none-eabi-gcc). I'm running into compiler errors however, and am questioning whether what I'm trying to do is possible.
The plugin I'm trying to set up is: https://github.com/vanhauser-thc/AFLplusplus/tree/master/gcc_plugin
I'm compiling the plugin on x86-64 linux using the -m32 flag, since the cross compiler is a 32-bit application. However when I try to use the plugin in the cross compiler using -fplugin , I get an undefined symbol compiler error:
cc1plus: error: cannot load plugin ../afl-gcc-pass.so
../afl-gcc-pass.so: undefined symbol: _Z13build_int_cstP9tree_nodel
I looked through the plugin's symbols using nm and discovered that the majority of symbols are undefined, including ones like exit and random. I'm new to most of this and am unsure of what that really means. Some searching online suggested that it may have had something to do with incorrect library paths, but setting LIBRARY_PATH and LD_LIBRARY_PATH and rebuilding did not seem to help.
The gcc version set-ups I have tried:
1: x86: 5.4.0 , arm: 5.4.1 on ubuntu 16.04
2: x86: 5.2.0 , arm: 5.2.1 on CentOS 6.8
Is it possible to use a gcc plugin in a different gcc than it was compiled with or am I wasting my time?
Yes, it is possible to build a gcc plugin with a given compiler and then use the plugin in another compiler (including a cross-compiler), but you have to make sure you include the right header files when building the plugin.
Specifically, you have to include the plugin development header files of the target compiler, instead of those of the host compiler. The directory where plugin development files for your target compiler are located can be obtained with the following command:
$(TARGET_CC) -print-file-name=plugin
where $(TARGET_CC) is your target compiler. So a concise way to specify the relevant include directory in the compiler flags when building the plugin would be something like -I"$(shell $(TARGET_CC) -print-file-name=plugin)/include".
For the specific plugin you are trying to use (instrumentation for afl-fuzz), in order to build the plugin for your cross-compiler you could modify the Makefile in the gcc_plugin folder; more specifically, you could define a TARGET_CC variable containing the path to your cross-compiler, and then replace $(CC) with $(TARGET_CC) in the definition of PLUGIN_FLAGS, as in:
PLUGIN_FLAGS = -fPIC -fno-rtti -I"$(shell $(TARGET_CC) -print-file-name=plugin)/include"
You will also have to comment out the commands executed in the test_build Makefile target, because those commands would try to use the plugin with the native compiler and so would fail.
Then, you will be able to use the plugin with your cross-compiler, as in:
arm-none-eabi-gcc -fplugin=../afl-gcc-pass.so --specs=nosys.specs my_source_file.c
Building TensorFlow with gcc version 4.8.5 or 5.4.0 gives an error:
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6:
version `GLIBCXX_3.4.20' not found (required by
bazel-out/host/bin/external/protobuf/protoc)
Tried to add linker flags in CROSSTOOL.tpl file in Tensorflow, however it didn't help.
You built your app with version of GCC that's newer than your host GCC. So your app uses symbols which are not present in host libstdc++ which causes runtime linker to fail.
You can solve this by linking your app with -Wl,-rpath,path/to/new/libs or setting LD_LIBRARY_PATH appropriately.
Using MinGW and CMake I've compiled LLVM, Clang and Compiler-RT both via SVN or using the released source code (3.2).
I've modified InitHeaderSearch.cpp (in tools/clang/lib/frontend) to find GCC 4.7.2 headers.
I've set the compile options to Release and disabled assertions.
Clang seems to work properly, but it takes 4-5 seconds to start: even typing "clang --version" in the console does this. Compiling a projects takes a lot of time.
What am I missing? I've used rubenvb's old MinGW+Clang build (GCC 4.6), and it didn't have this problem. Is there any compilation flag I need to use?
This issue is discussed here http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-April/020651.html
AFAIK problem is caused by large relocation table and inefficient MinGW implementation (http://sourceforge.net/p/mingw/bugs/1747/).
Adding -static flag to linker flags should resolve this issue. You should invoke cmake with
-DCMAKE_EXE_LINKER_FLAGS=-static -DCMAKE_MODULE_LINKER_FLAGS=-static
I am trying to build a library (luabind) with bjam. I came across an error and it seems like the problem is that I need to compile with gcc 4.2, but the default on this computer (Mac OSX) is 4.0. I would prefer not to go around changing links in system directories, is there a way to specify to bjam to use gcc4.2 rather than just gcc?
I think it's described in the documentation. You should have:
using gcc : 4.2 : g++-42 ;
in your user-config.jam and "bjam toolset=gcc-4.2" on the command line
Try running bjam with these options:
--toolset=gcc --toolset-root=/path/to/gcc/4.2