如何在Windows上使用Visual C ++强制加载链接库

Question

I am trying to handle a project with multiple dynamic libraries, in the libraries some global objects are created and registered in a list so that the executable can use them to build other things. In the executable there's no reference to any function of any library, it just needs the objects, and then it knows what to do. These libraries are intended to work like plugins that are chosen at link time.

Ideally when compiling ExecutableProject I link LibraryA , an object of type A gets created (by some code that's compiled in the library) and ExecutableProject does things because of it, using functions in LibraryA . If instead I link LibraryB then an object of type B gets created and other things happen.

The problem is, since ExecutableProject does not directly use any function or class in the library, the library is not loaded, and objects are never created.

I have found some workarounds:

1. I can use /INCLUDE:symbol at link time when compiling ExecutableProject , where symbol is any symbol exported in LibraryA or LibraryB . I don't like this because I have to know the decorated name of a function in the library, which is not always available. Also, it's not elegant.
2. I can use a dummy variable. I could put __declspec(dllexport) int force_link_A_or_B; in LibraryA and LibraryB and __declspec(dllimport) extern int force_link_A_or_B; in ExecutableProject . I don't like this because if I had more libraries I'd have to add a variable for each of them. Basically although the code in ExecutableProject does not know which libraries will be linked, it still needs to know how many of them can be linked together.

On Linux, using gcc and ld, it's very easy to solve this problem, all it takes is a simple linker flag -Wl,--no-as-needed . Is there any way to do this using Visual Studio? I would be happy if there was something that worked like /INCLUDE but used entire libraries instead of symbols and did not need decorated names.

Thanks

EDIT: I have been asked to clarify how this design is intended to work. Ideally, when I compile ExecutableProject I link LibraryA or B and an object is created.

`ClassA A;`

This is placed outside all functions in a source file that is compiled in LibraryA . Same thing happens in LibraryB . The key here is that ClassA and ClassB inherit from a BaseClass that ExecutableProject knows well. When the object is created, the BaseClass constructor is run, and inside it a BaseClass* pointer pointing to this (therefore the derived object) is saved, and ExecutableProject uses that pointer. It does not need to know anything about the derived classes, because it uses only a BaseClass pointer, but when it calls virtual functions from it, different functions are executed depending on the actual type of the pointed object. If there were more objects instead that just two alternatives, I would save BaseClass pointers in a list or a map, and let ExecutableProject access it.

Answer 1

Don't try this. The design is fundamentally flawed.

In particular, since you are not making any explicit calls to the DLL, you would rely only on object A being created via an implicit call to DllMain .

But under Windows rules, you are barred from doing anything interesting in or from DllMain , so object A cannot be very useful.