When using a mingw-w64 toolchain, I see that the linker is linking stub libraries instead of linking directly. For example, the linker will choose to link to libkernel32.a which is an import library.
This sparked my curiosity and brought up the following questions:
libws2_32.a has source code compiled within it. I disassembled it and found that it contained both stubs and code - as if it were a import library and static library mixed. Is this normally possible outside of the MinGW environment - to have an import library containing valid code?Sources: https://github.com/mirror/mingw-w64/tree/master/mingw-w64-crt/libsrc/ws2tcpip
libws2_32.a then the linker deduces that the runtime DLL is ws2_32.dll. Is this an implementation-specific feature or is there an agreed convention to store and locate the original DLL name?There's no technical reason that an import library can't contain statically linked entry points.
You'd want to check whether this works properly, but one way that might get you there is to do a postprocess step on the import library to add the static linked objects to it.
This page includes the following notes:
You can use LIB to perform the following library-management tasks:
- To add objects to a library, specify the file name for the existing library and the filenames for the new objects.
Provided this operation doesn't remove the DLL import information, it should allow you to create such a library. I'm at work right now, on a Mac, so I don't have access to VS on my Windows system at home to test this for sure.
As to how the linker knows the name of the DLL involved, that's embedded in the import library, and from there gets embedded into the final EXE.