How to change character scope in CMake or Visual Studio?

Question

visual studio

The story is old - plugins. Same interface, different implementations. C-ABI, plugins are not expected to use anything outside the capabilities of the standard library.

Shared/dynamic libraries loaded at runtime work without problems.

But the thing is that I need to be able to include in the standard assembly a certain minimum set of plugins, so to speak, what is available by default. A set of plugins built into the binary. On the one hand, it should be a static link, on the other hand, a symbol conflict is inevitable. Well done Linux, Linux has objcopy --localize-symbol <symbol> <file>, so I was able to successfully make a proxy function with a unique name in a separate file, link it into one translation unit (ld --relocate impl1.o proxy1.o -o lib1.o) and make all plugin symbols static in this frankenstein, leaving only the unique proxy name outside.

I can't find how to do this on Windows. Initially, I was looking for how to do this using CMake, I did not find it, but suddenly someone knows - it would be ideal.

Question : how to hide symbols from the linker using Windows tools, or better CMake? Or how else should one approach this problem and why only in this way?

Immediately my options for other approaches to the problem and justifications why not them:

• There is an option to drag a Linux stack into Windows in the form of some MinGW, Cygwin. Or sell your soul to clang and use llvm-objcopy. But these are additional installations and settings and not quite cross-platform, moreover, it is labor-intensive for the plugin developer.
  
• Perhaps we should go into code generation: declare an interface and oblige the plugin developer to report which function implements which interface. The problem is the naive hope that the symbols of different plugin developers will be unique.
  

Thanks

Answer 1

Overengineering right in the face.
Why not just carry a set of standard plug-ins along with the program? In any case, it will not work to distribute the program with one file - if this is done via the Internet, it would be nice to reap the program, plus, attach the ability to download the required Redist to it.
Criticized, now I suggest:
Make each plugin's exporter function unique, but recognizable. When loading a plugin, merge the list of exported functions from the DLL, parse it at least regularly and find the entry point.

Answer 2

01.2022. So far I am limited to llvm, with such steps.