abi

I have two scenarios. Suppose I have 3 shared libraries that export C++ symbols, each built with VS7.1, VS8, and VS9. I compile all 3 in VS9. For some reason, this works. I do not need to recompile the first 2 libraries in VS9 for VS9 linker to successfully find the symbols and link against them. Now, if I have a library that only exports symbols using C syntax (extern "C"), is this the same? I've heard people say that the ABI for C is standardized, so there is somewhat of a guarantee that you can use a C library compiled in Visual Studio 8 in all versions of Visual Studio. Basically, the

I've been reading through Clang source code and discovered something interesting about the ARM C++ ABI that I can't seem to understand the justification for. From the an online version of the ARM ABI documentation : This ABI requires C1 and C2 constructors to return this (instead of being void functions) so that a C3 constructor can tail call the C1 constructor and the C1 constructor can tail call C2. (and similarly for non-virtual destructors) I'm not sure what C1 , C2 , and C3 reference here...this section is meant to be a modification of §3.1.5 from the generic (i.e. Itanium) ABI, but that

clang++ and g++ are ABI incompatible, even for things as core as standard containers, according to, e.g., the clang++ website. Debian ships with C++ shared libraries, i.e. libboost, etc... that are compiled with ~something and user programs using both compiler generally work, and the library names aren't mangled with the compiler that was used for them. When you install clang, debian doesn't go and pull in duplicate versions of every C++ library installed on your system. What's the deal? Is the ability of clang to link against distro-provided C++ libraries just way stronger than the

I have downloaded a library that was compiled with a gcc 4.8 before the ABI change in GCC. On my laptop (latest kubuntu) I have GCC 5.2. And When I installed boost, it seems that it used the new ABI but then I get the following link errors undefined symbol.....__cxx11.... How can I install boost using old ABI with GCC5 ? To my knowledge, there are no prebuilt Boost packages for the old ABI in the official Kubuntu repositories, so you will have to build Boost yourself. The building process is documented here . Make sure you're building the same Boost version that was used when your library was

The pimpl idiom is commonly used in order to allow changing code in dynamically linked libraries without breaking ABI compatibility and having to recompile all the code that depends on the library. Most of the explanations I see mention that adding a new private member variable changes the offsets of public and private members in the class. That makes sense to me. What I don't understand is how in practice this actually breaks the dependent libraries. I've done a lot of reading on ELF files and how dynamic linking actually works, but I still don't see how changing the class size in the shared

For example could I mix a set of libraries that have been compiled in say GCC-4.6 with GCC-4.9. I'm aware different compilers "breeds" such as VS cannot be with MinGW but can different generations of the same compiler? Are issues likely to occur? If so what? Different generations of the same compiler sometimes can be compatible with each other, but not always. For example, GCC 4.7.0 changed its C/C++ ABI , meaning libraries compiled with 4.7.0+ and 4.7.0- are not likely to be compatible with each other (so in your example, the library compiled with 4.6 will not be compatible with the library

I'm having some trouble understanding the difference between caller and callee saved registers and when to use what. I am using the MSP430 : procedure: mov.w #0,R7 mov.w #0,R6 add.w R6,R7 inc.w R6 cmp.w R12,R6 jl l$loop mov.w R7,R12 ret the above code is a callee and was used in a textbook example so it follows the convention. R6 and R7 are callee saved and R12 is caller saved. My understanding is that the callee saved regs aren't "global" in the sense that changing its value in a procedure will not affect it's value outside the procedure. This is why you have to save a new value into the