binary-compatibility

Are the three main compiler flavors supported by Xcode (gcc 4.0, 4.2, and llvm) binary-compatible with one another? What kind of gotchas and corner cases should I be aware of when bringing a multi-library project up to speed with the most recent Xcode tools? Clang is ABI-compatible with code generated by gcc. Clang also includes experimental support for some newer Objective-C ABIs, but compiling for the newer ABI requires flags, and generated code can be mixed with GCC-generated code anyway. A minor gotcha is that if you want to compile PowerPC code that will run on a G3, you must use GCC 4.0.

Can it be done before compiling, by comparing code? Is there any tools already doing this? okun You might find this interesting: Static analysis tool to detect ABI breaks in C++ ABI Compliance Checker — a tool for checking backward API/ABI compatibility of a C/C++ library: abi-compliance-checker -lib NAME -old OLD.abidump -new NEW.abidump *.abidump files are ABI dumps of OLD and NEW library versions generated by the ABI Dumper tool. icheck - C interface ABI/API checker: icheck --canonify -o old_version -I/usr/include/foo/ bar.h icheck --compare -o results.txt old_version new_version shlib

There's a standard pattern for events in .NET - they use a delegate type that takes a plain object called sender and then the actual "payload" in a second parameter, which should be derived from EventArgs . The rationale for the second parameter being derived from EventArgs seems pretty clear (see the .NET Framework Standard Library Annotated Reference ). It is intended to ensure binary compatibility between event sinks and sources as the software evolves. For every event, even if it only has one argument, we derive a custom event arguments class that has a single property containing that

I am designing an API for a C++ library which will be distributed in a dll / shared object. The library contains polymorhic classes with virtual functions. I am concerned that if I expose these virtual functions on the DLL API, I cut myself from the possibility of extending the same classes with more virtual functions without breaking binary compatibility with applications built for the previous version of the library. One option would be to use the PImpl idiom to hide all the classes having virtual functions, but that also seem to have it's limitations: this way applications lose the

I'm currently developing a C++ library for Windows which will be distributed as a DLL. My goal is to maximize binary interoperability; more precisely, the functions in my DLL must be usable from code compiled with multiple versions of MSVC++ and MinGW without having to recompile the DLL. However, I'm confused about which calling convention is best, cdecl or stdcall . Sometimes I hear statements like "the C calling convention is the only one guaranteed to be the same accross compilers", which contrasts with statements like " There are some variations in the interpretation of cdecl ,

At the Spark 2.1 docs it's mentioned that Spark runs on Java 7+, Python 2.6+/3.4+ and R 3.1+. For the Scala API, Spark 2.1.0 uses Scala 2.11. You will need to use a compatible Scala version (2.11.x). at the Scala 2.12 release news it's also mentioned that: Although Scala 2.11 and 2.12 are mostly source compatible to facilitate cross-building, they are not binary compatible. This allows us to keep improving the Scala compiler and standard library. But when I build an uber jar (using Scala 2.12) and run it on Spark 2.1. every thing work just fine. and I know its not any official source but at

I want to verify binary compatibility between 2 JARs. Following the suggestions in this answer I used jboss tattletale but it can find only missing classes. How can I find if there are missing methods? Is it possible at all? E.g. "Depends - on" class Foo depends on Bar (like many other middle class workers) import org.overlyusedclassnames.Bar public class Foo{ public void someMethod(){ Bar tender = new Bar(); tender.getJohnnyRedLabel(); tender.getJohnnyBlueLabel(); //this method is new in the Bar class } } "Compile time" class package org.overlyusedclassnames; /** * @Since 1992 * Changes:

I found this tool, http://sab39.netreach.com/Software/Japitools/JDK-Results/46/ , which checks for backwards compatibility between different versions of APIs for Java using javadoc. Is there an tool equivalent to this one for C#/.NET? Here is an example of a comparison between JDK 1.5 and JDK 6 APIs using this tool: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-jdk6 ApiChange does take a set of "old" assemblies and a set of "new" assemblies which are diffed for potentially breaking Api changes: ApiChange -diff -old HelloWorldV1.dll -new HelloWorldV2.dll LibCheck allows you to compare two

Why is Scala binary incompatible between different releases? It has to do with the way traits are compiled, because traits are kind of like interfaces but they can contain implementation. This makes it so it is VERY easy to make changes that don't break source compatibility but break binary compatibility, because when you add a new method to a trait along with an implementation, you have to recompile everything that implements that trait so that they will pickup that implementation. There's probably other issues, too, but I think they're mostly along the same lines. Lack of JVM support for