I'm compiling a library using g++, using following parameters:
g++ -gdwarf-2 -std=c++0x -m32 -Dunix=1 -Dlinux=1 -D_JAVA=1 -DNDEBUG=1 -I...
Although I'm using specific DWARF version 2, the investigation of my core-file keeps on giving following error message:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2)
Does anybody know what I can do?
I'm working with following versions:
Platform version : CentOS 5.2
g++ version : g++ (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52)
gdb version : GNU gdb Red Hat Linux (6.5-37.el5rh)
It is not possible to update the platform.
For your information: meanwhile I've found this URL (http://www.delorie.com/gnu/docs/gdb/gdb_17.html), which explains that sometimes it might be a bad idea to mix debugging information with optimisation flags.
As a result, I have removed the optimisation flag (although it was "-O0", and I have used "g++ -gdwarf-2 -g3" (as mentioned in the URL), but still no improvement.
Meanwhile I've solved the problem, by updating my GDB (and related) processes.
Related
I am currently trying to use Oracle Linux 6 OS on a SPARC S7 server to run the NPB benchmarks (with OpenMP multithreading support). The OS comes preloaded with gcc 4.4.7, which is missing the Niagara 7 optimizations. I downloaded devtoolset-3 from the Oracle Yum Repository, which has gcc 4.9.2 installed in /opt/rh/devtoolset-3/root/usr/bin. However, when I compile the NPB benchmark using the newer gcc, it automatically links to libraries associated with the older gcc 4.4.7 (located in /usr/lib). This caused my program to segfault during execution. I believe that it is because libgomp 4.4.7 is incompatible with libgomp 4.9.2. I have tried several ways of linking to the libraries in the gcc 4.9.2 folder (which is /opt/rh/devtoolset-3/root/usr/lib/gcc); none of the methods work:
-Xlinker -rpath=lib_location
-Wl -Bstatic
-L lib_location
The closest I got was when using -Wl -Bstatic ~/libgomp.a or -static -L ~/libgomp.a. It fails to find libraries such as libm that reside in the default gcc lib folder (usr/lib).
The actual command used to link is:
/opt/rh/devtoolset-3/root/usr/bin/gcc -O3 -fopenmp -mcmodel=medmid -static -L/opt/rh/devtoolset-3/root/usr/lib/gcc/sparc64-redhat-linux/4.9.2 -o ../bin/bt.W.x bt.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o rhs.o x_solve.o y_solve.o solve_subs.o z_solve.o add.o error.o verify.o ../common/print_results.o ../common/c_timers.o ../common/wtime.o -lm -L/opt/rh/devtoolset-3/root/usr/lib/gcc/sparc64-redhat-linux/4.9.2/lib/
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lm
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lrt
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lpthread
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lc
Is there a way I can link just the libgomp library from gcc 4.9.2 while linking the remaining libraries from gcc 4.4.7?
The devtoolset compilers are all using the system libgcc, libstdc++, version 4.4.7, and can therefore not compile e.g. c++11.
I guess the gcc53-c++-5.3.0-1.el6.x86_64.rpm will do. Comes with the internal */gcc53/lib64{libgcc_s.so**, libgomp.so**, libstdc++} (version 5.3.0) ... Provides /usr/bin/{ gcc53, g++53 }
The package was created a year ago ... well tested, as extra compiler. Download link : https://drive.google.com/file/d/0B7S255p3kFXNbTBneHgwSzBodFE/view?usp=sharing
If you're going to do the -Wl,-Bstatic thing, make sure to follow it immediately by -Wl,-Bdynamic to reset to normal after your added library argument. By default, not all system libraries have static versions installed, which is why you get e.g. cannot find -lc.
So you can try this as a modification of your workaround:
-Wl,-Bstatic ~/libgomp.a -Wl,-Bdynamic
Not pretty, and this question deserves a much better answer (this is still pretty much a hack), but it should get the job done for now.
I'm trying to use clang++ as drop-in replacement for G++. I'm compiling for AArch64, but for linking, clang seems to invoke the native (x86) /usr/bin/ld instead of that from AArch64 GCC suite. The clang command line looks like:
clang++ -target aarch64-linux-gnu -v \
-gcc-toolchain /path/to/aarch64/gcc \
--sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc \
<some other options> <obj files>
And from the verbose output, I get:
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: aarch64--linux-gnu
Thread model: posix
Found candidate GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
Selected GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
"/usr/bin/ld" --sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc ...
I don't get why clang got around choosing the native linker. The link fails for obvious reasons that object files are AArch64 ELF. Compilation lines similar to the above, but they go OK.
Any thoughts?
PS: I'm a novice clang user
I managed to find a solution: GCC accepts -B option to point to the search path where it'd try to locate the utilities. It turns out--although not documented--that clang too accepts this option. For me, having -B point to AArch64 binutils solved the problem. Another suggestion was to add the AArch64 binutils in $PATH.
I am compiling code to run on an arm neon and the make files have the following command line included.
-mcpu=cortex-a9 -march=armv7 -mfpu=neon -DARM_NEON
The details of GCC version are as follows:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
However when I try to compile, gcc keeps throwing the following error:
gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
gcc: error: unrecognized command line option '-mfpu=neon'
I am pretty sure that the code could be compiled previously. Though a long time ago. Could it be changes in version of GCC? or is it do with 32 bit and 64 bit compilers?
I was trying to cross compile for an arm processor on my intel x86_64 Ubuntu machine. I needed to add the configuration for the host in the makefiles and use arm-linux-gnueabihf-gcc instead of gcc.
I have two workstations, one of them runs Debian Wheezy and has gcc 4.9.2
Second one runs RHEL 5.5, gcc version is 4.8.2
when I compile the same code with the same options:
$gcc -O3 -DNDEBUG -g -o test test.c
I get all the necessary debugging information on gcc 4.9 on Debian box, however on RHEL box objdump says:
$ objdump --debugging test
test: file format elf64-x86-64
objdump: test: no recognized debugging information
What do I do wrong?
From looking around, this appears to be a known bug or limitation in objdump:
https://bugzilla.redhat.com/show_bug.cgi?id=118383
https://sourceware.org/bugzilla/show_bug.cgi?id=6483
How can I tell if a library was compiled with -g?
Suggested workarounds are using objdump -W, readelf -w, or gcc -gstabs.
I'm not a linux expert but I'm running into the following problem which I hope to get solved here. My system has gcc 4.4 and I had to install an older version of gcc (gcc 4.2) on my home space so I can build a simulation tool.
Anyway, everything went well and I was able to build the tool.
However, when I now try to link statically using '-static' gcc option I get errors such as:
/usr/local/bin/ld: cannot find -lm
/usr/local/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
I installed the dev package for glibc using (assuming the static version of the libraries will be installed)
$ yum install glibc-devel glibc-static
But I still get the errors.
I don't know where to go from here.
By the way, I added the local version of gcc (ie gcc 4.2) to PATH and the libs to the LD_LIBRARY_PATH and LIBRARY_PATH.
Do I need to get glibc and install it locally too, if so which version should I get?
Thanks