c++windowsdlldllimport

How dynamic linking reacts on a change in object

I have compiled a component (say X.exe) linked with a dynamic library (say Y.dll). X and Y have been released.

Now I have made a small change in an object's function which Y holds: I've deleted a leaked object and made its pointer NULL.

To apply this change with full compatibility what should I do?

  1. Need to recompile component X with the new library file and need to replace the DLL as well;

  2. Recompiling X with new library file would be enough;

  3. Replacing the DLL would be enough.

Solution

  • Now I have made a small change in an object's function which Y holds.

    What need to be done depends on the specific change you made. For those types of situation, we can discriminate between two types of changes: ABI-breaking changes, and ABI-compatible changes.

    ABI (Application binary interface) is the interface of a compiled object at the binary level. Similarly of the way C++ functions have an API (e.g. the function's signatures are part of an API), compiled machine language have an ABI which depends on the API and the calling convention, amongst other things.

    Knowing what changes are ABI-breaking and which are not can sometime be a difficult task. But as a rule of thumb:

    Now, if you broke Y's ABI, you should release a new version of it (let's call it Y-2). X won't be compatible with Y-2 and would require to be upgraded (optionally) and recompiled (mandatory) and released as a new version (let's call it X-2). X and Y-2 are not ABI compatible. X-2 and Y are not ABI compatible.

    If Y's ABI is untouched, you can safely distribute your new version of Y (let's call it Y-1.1) which will replace Y on target computers and link with the original X.

    From a comment, it appears that:

    The change I have done is just deleting a leaked object and made it to NULL.

    This is neither an API not ABI breaking change. You can safely distribute Y-1.1 only.