How dynamic linking reacts on a change in object

Question

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.

Answer 1

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

What kind of change? Only if you have changed the method's signature, and X.exe is dependent on this method, then you must recompile component X with the new Library file and Need to replace the DLL as well. Otherwise, Replacing the DLL would be enough.

Answer 2

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 as 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:

• if you did not change Y's API, Y's ABI is unchanged;
• if you did change Y's API, Y's ABI is changed.

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.

Answer 3

It's depend on the changes you made in the DLL source code. If there is any function addition/deletion then you need to follow step 1. If there is only change in the function body of the DLL source code then step 3 will work. Step 2 is not applicable, as in any case you need to replace a new DLL.