[wahern]

On Linux and maybe Solaris you can use ELF symbol versioning.

Otherwise, if the concern is both libfoo, libbar, and bin/acme linking to liblfds, then they should be linking it statically. Either liblfds or the depending code (libfoo, libbar, and bin/acme) can be compiled in such a way that liblfds symbols do not leak outside the component they're used in. On modern systems you're not limited to static or extern linkage scopes, even across compilation units.

Windows might be difficult. But shared, dynamically linked DLLs aren't common on Windows. At least, not in the sense where the DLL can be sourced independently. That's because historically DLLs were only compatible with code compiled with the same Visual Studio release (because CRT intrinsics and data structures were not backwards or forwards compatible), which meant that in practice you always bundled dependencies, even if dynamically linked, to ensure everything was compatible.

[liblfds]

> On Linux and maybe Solaris you can use ELF symbol versioning.

Remember that the library supports bare metal platforms. It is intended to be used in the absence of an operating system.

I'm afraid I'm not sure I undersand what you've written.

My aim is to ensure that for applications using the library, that when a new release comes out, that they can use it while seeing absolutely no change in the code they are already using (header files, the binary being linked to, etc), as this is the and the only way to know that existing code will be wholly unaffected.