binary-compatibility

问题 https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017 says that C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017 is guaranteed except: 1)When static libraries or object files are compiled with the /GL compiler switch. 2)When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume

问题 This SO post: Is Visual-C++-2017 binary compatible with VC++-2015? clearly says that VS 2017 is binary compatible with VS 2015. It even looks like the official position. My question is, in the past, I distinctly remember running into linker errors (I do not recall the specific set of errors) every time I try to link in a static library that was compiled with a different version of MSVC into an EXE that is being built with a newer version of MSVC. Yet, binary (in)compatibility sounds like

问题 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? 回答1: 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

问题 It is my understanding that ARMv7 processors, such as the Cortex-A9, are mostly backwards-compatible with code for older ARM architecture versions. However, I've read reports of segfaults trying to run ARM9 code on a Cortex-A8, for example. What parts of ARMv4/5/6 (ARM7TDMI/ARM9/ARM11) code will not work on an ARMv7 processor? What features or architectural characteristics exist in these older ARM architecture versions that can cause a program built for these versions to fail on ARMv7? 回答1:

问题 If I get some C++ code built by, lets say, GCC 4.8 on Ubuntu, the code has no GUI/interface, only call standard Linux libraries, then can the binary run on RHEL 5/6, with much older GCC flawlessly? 回答1: Normally it can't. It will complain about libc being too old, for one. If you statically link with libstdc++ and carefully avoid newer glibc features, you may be able to get away with it. The latter is not always possible though. Static linking with libc is not officially supported and may

问题 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

问题 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? 回答1: 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

问题 I have vb6 com server (ActiveX DLL project) that is used by .NET code Everytime I put changes into vb6 code and make dll, I have to recompile my .NET client code as well, because it looks like VB6 generates new GUIDs or versions to interfaces and com-objects. I admit it's a good practice because changes are made but I'd like to disable this behavior to let my .NET client code be the same everytime I update my vb6 dll. How can I tell VB6 to keep all GUIDs and versions for ActiveX dll the same

问题 Could someone explain to me why adding a virtual function to the end of a class declaration avoids binary incompatibility? If I have: class A { public: virtual ~A(); virtual void someFuncA() = 0; virtual void someFuncB() = 0; virtual void other1() = 0; private: int someVal; }; And later modify this class declaration to: class A { public: virtual ~A(); virtual void someFuncA() = 0; virtual void someFuncB() = 0; virtual void someFuncC() = 0; virtual void other1() = 0; private: int someVal; }; I

问题 I'm curious if the default constructor and destructor that the compiler generates are inline or not, because I can justify it either way. On the one hand, you want the default constructor/destructor to not be inline so that adding them later doesn't break ABI (because object files compiled when only the defaults were there will have inlined the generated definitions instead of what you define). On the other hand, for a C++ compiler to compile C code that performs as well as when compiled with