Why doesn’t the following C++ program have a link conflict with the system-provided __cxa_throw ? Is there something magical about that symbol? For a normal function this would be an ODR violation wouldn’t it? Answer As @Igor pointed out, you need to add extern “C” to prevent name mangling. But the cause why it works is because the symbol is
Tag: libstdc++
glibc ( or libc6 ) library version
I am trying to figure out what is the correlation between the version from “GCC->ABI Policy” and the version from ldd –version From ABI Policy and Guidelines I see that for my GCC 4.8.4 I should have: When I run ldd –version I get: I don’t understand the corelation between this two version numbers. I would like to upgrade to
Seg fault when app & shared lib built with -static-libstdc++
If I build a C++ app with -static-libstdc++ which loads a shared lib (via dlopen) which was also built with -static-libstdc++, then the app seg faults during dlopen. BUT–this only happens in some setups: GCC 4.7.4, 32-bit: pass GCC 4.8.3, 32-bit: pass GCC 4.8.4, 64-bit: pass GCC 4.9.2, 64-bit: pass GCC 4.9.3, 32-bit: FAIL (unless RTLD_DEEPBIND is specified) GCC 4.9.3,
gcc 4.x not supporting x87 FPU math?
I’ve been trying to compile gcc 4.x from the sources using –with-fpmath=387 but I’m getting this error: “Invalid –with-fpmath=387”. I looked in the configs and found that it doesn’t support this option (even though docs still mention it as a possible option): Basically, I started this whole thing because I need to supply an executable for an old target platform
libstdc++.so.5: cannot open shared object file – but library is installed and up-to-date
My client had some developer write a small c++ command-line app to run on their Linux servers. On one of the servers (running Fedora 11), when I execute the app I get the following error: Obviously the first thing I did was But I get So the library already exists and is up-to-date. Usually to me these errors indicate a