Unix linkers give an error if any symbol is defined in multiple object files, different or not. After all the object files have been combined, remaining undefined symbols are resolved by searching the specified libraries in command line order. Each object from a library that provides a needed definition is selected and its undefined symbols are added to the global list. Some linkers will scan the libraries a second time in order to resolve interdependencies. If at the end of this, the combined set of object files (from command line and from libraries) contain more than one definition for any symbol, an error is raised. The MSVC linker is apparently much more lax in this regard.

With the inline semantics defined by C99 there are two solutions to this problem:

1. Use static inline. Any non-inlined calls will result in an instance of the function with internal linkage. Aside from wasting space with multiple copies of the same function it is harmless. As mentioned, an optimising linker might even merge identical functions across compilation units.

2. Use inline without explicit extern. Non-inlined calls result in an undefined external reference to be resolved by the linker with a definition provided elsewhere. The inline definition is only used when the function is actually inlined and never provides a non-inline definition of the function, internal or external.

Neither of these approaches result in duplicate definitions with external linkage, so the described problem cannot arise.

It's disappointing that Microsoft seem to have chosen the one approach to inline functions that results in this sort of breakage.