当在窗户下研究Scintilla的makefile为MinGW时，我注意到它将-shared和-static一起作为LDFLAGS传递给gcc。
LDFLAGS=-shared -static -mwindows $(LDMINGW)
我用Google搜索，只从clang中找到一些信息：https://reviews.llvm.org/D43811
[MinGW，CrossWindows]允许-shared与-shared一起传递
In these combinations, link a DLL as usual, but pass -Bstatic instead of -Bdynamic to indicate prefering static libraries.
我的问题是：海湾合作委员会会这样做吗？ 我还没有找到任何证据。
您可以在GCC链接中传递-static和-shared。它们的组合效果与您在llvm链接中描述的相同，并且GCC一直都是如此。
-shared指示GCC链接生成共享库而不是程序，它通过将选项-shared传递给它的链接器调用来实现。
在解析输入库选项-static时，-lname指示GCC链接忽略共享库。默认情况下，-lname将通过搜索指定的或默认的链接器搜索目录来解析共享库libname.so（在Windows上，[lib]name.dll）或静态库libname.a（在Windows上也是[lib]name.lib）并且如果找到它们两者则更喜欢共享库在同一目录中。 -static只是从搜索中排除所有共享库。 GCC通过将选项-Bstatic传递给它在所有-lname选项之前生成的链接器命令行中的位置调用链接器来实现此目的。
GNU linker documentation of -Bstatic明确表示此选项与-shared一致，并且效果是生成一个共享库，其所有依赖库已经静态解析。
-Bstatic
-dn
-non_shared
-静态的
不要链接共享库。这仅对支持共享库的平台有意义。此选项的不同变体是为了与各种系统兼容。您可以在命令行上多次使用此选项：它会影响库搜索后面的-l选项。此选项还意味着--unresolved-symbols = report-all。此选项可与-shared一起使用。这样做意味着正在创建共享库，但必须通过从静态库中提取条目来解析所有库的外部引用。
（强调我的）。
虽然共享库的静态链接原则上只是一个与程序的静态链接相同的链接限制，但实际上它经常遇到Unix和Linux上的障碍，因为链接到ELF共享库libname.so的所有目标代码必须是Position Independent Code ，由GCC编译选项-fPIC生成，而注定要在静态库中存档的目标文件通常不使用-fPIC编译。因此，使用-shared ... -static的链接很容易失败，因为必要的静态库包含非PIC对象文件。
但是，在Windows上没有GCC的担心，因为在Windows PE目标代码中没有PIC v.non-PIC这样的区别。