binary-compatibility

Now, I know it is generally bad to add new virtual functions to non-leaf classes as it breaks binary compatibility for any derived classes which haven't been recompiled. However, I have a slightly different situation: I have an interface class and implementation class compiled into a shared library, for example: class Interface { public: static Interface* giveMeImplPtr(); ... virtual void Foo( uint16_t arg ) = 0; ... } class Impl { public: ... void Foo( uint16_t arg ); .... } My main application uses this shared library, and could basically be written as: Interface* foo = Implementation:

I have been looking around for an ABI cross-check tool. Now I have met some of the tools suggested in other questions, such as in these questions: How to test binary compatibility automatically? Static analysis tool to detect ABI breaks in C++ Now, this is not exactly what I am trying to do - as these track ABI changes between versions. I was wondering that given project source files + library header file and library .so file, as well as a compiler version (which is used for compiling both the library and the project), is it possible to cross check that the output of the ABI matches the

What changes or code evolution break backward compatibility (mainly binary compatibility)? Is it fully specified anywhere? I checked the Scala language specification , but didn't see any section on the matter like Java Language Specification Ch. 13 Binary Compatibility . huynhjl According to the mailing list, the spec documenting detailing backward compatibility issues does not yet exist but is in the works. For current status and oulook of binary compatibility (mainly of the scala library), see Martin's message to scala-user mailing list. For a migration manager preview, see this page http:/

I need to verify something for which I have doubts. If a shared library ( .dll) is written in C, with the C99 standard and compiled under a compiler. Say MinGw. Then in my experience it is binary compatible and hence useable from any other compiler. Say MS Visual Studio. I say in my experience because I have tried it successfully more than once. But I need to verify if this is a rule. And in addition I would like to ask if it is indeed so, then why libraries written completely in C, like openCV for example don't provide compiled binaries for every different OS? I know that the obvious reason

I am confused regarding backward compatibility when adding a method with default implementation to a trait. Like: Previous Version trait Foo New Version trait Foo { def verifyConsistency: Option[String] = ??? // provide default implementation } The Migration Manager reports this addition as a binary incompatibility. Is that correct? Well yes it is correct. When you define trait Foo , it will under the hood create both a (JVM) interface Foo and a (JVM) class Foo$class with all the method implementations defined as static methods. The corresponding java code would look like something like this

Any way to make a binary in a Linux distribution and run it on another distribution with same architecture? Or I should compile and build it on different distributions? Is there any compatibility between Redhat, Debian based distributions for binary files? (I want to use my Ubuntu binary file on fedora!) Enter Linux Standard Base to reduce the differences between individual Linux distributions. See http://www.linuxfoundation.org/collaborate/workgroups/lsb http://en.wikipedia.org/wiki/Linux_Standard_Base Statically linking your binaries makes them LESS portable because some libraries won't then