top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Version CXXABI... not found when compiling program with gcc

+2 votes
1,035 views

I am getting following error when compiling my program with gcc version 4.9.0

gcc --version
gcc (GCC) 4.9.0 20131023 (experimental)

Error

./A.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./A.out)

But I gcc 4.7.3 is fine. Any guess why this may be happening.

posted Nov 30, 2013 by Sonu Jindal

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

It means the version of libstdc++.so.6 being found by the dynamic linker at run-time is older than the version of libstdc++.so.6 that was used at link-time. That usually happens because you use a new version of GCC to compile and link, but do not tell the dynamic linker how to find the libraries from the new GCC.

See http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
and the section of the manual it links to.

answer Nov 30, 2013 by anonymous
Similar Questions
+5 votes

GCC is stripping the object file when nothing from the file is being used anywhere in the executable (even -o0 does nor help). We have to disable this feature of linker g++. could any one please help us to resolve this issue??

+1 vote

If I compile c++ code, I am supposed to use g++. This automatically does some magic that calling just Gcc would not do. The same with Fortran code and gfortran. So my question is which frontend should I use to link if I have object files from both c++ as well as Fortran, c, and maybe another language still?

0 votes

I recently encountered a problem with a function was marked as a constructor. The source file was compiled with -O0, but it appears the function was optimized to the point it skipped some of the startup
code and jumped into the failure state (which called exit). I was able to restore desired behavior with '#pragma GCC optimize("O0")' around the function (even volatile tricks did not help).

The startup code had to do with an integrity check. The expected fingerprint was back-patched after compiling, and then recalculated at runtime. Then, a memcmp was made. It appears the compiler deduced that the allocation was a string of 0's and could never be equal to the runtime fingerprint, so its just omitted the code.

Is this expected behavior for functions marked as constructors (compiled with -O0)?

0 votes

We are trying to build our code base for CentOS 7 machine with x86_64 architecture on CentOS6 with x86_64.

For that we are trying to build a centos7 Toolchain. All the gcc/ld/ar should be statically linked, so that we are ensuring that it will not uses any native centos6 stuff.

In this process, we are able to generate statically linked GCC/AR/LD. But problem was this GCC not generating a statically linked binaries and fails while checking flags during configure at "checking static
flag -static ". Due to this while running those binaries it refers to native libgcc and fails.

We are using the below command for configure.

../gcc../configure -prefix=/mnt/data0/toolchain-vm-temp2 --build=x86_64-CentOS7-linux-gnu-with sysroot=/mnt/data0/tools/gnutools/toolchain-vm --disable-nls --disable-multilib --enable-languages=c,c++ --disable-sim --enable-symvers=gnu --enable__cxa_atexit --enable-lto --with-gnu-ld --enable-static

Can Anyone provide solution or how to achieve this task.

0 votes

When I was building GCC, I found out that stage1-gcc is not compiled with optimization (such as -O2). So the compilation of stage2 is very slow. Is this intended or not? If not, did I made some mistakes in configure options and caused this?

...