https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921
--- Comment #13 from Keith Marshall <keith.marshall at mailinator dot com> --- (In reply to Eric Botcazou from comment #7) > > With that in place, a clean configure and build does now produce: > > > > gcc/ada/rts/libgnarl-6.dll > > gcc/ada/rts/libgnat-6.dll > > > > but there are no accompanying import libraries, (as there are for other > > DLLs, produced for other languages in the GCC suite). Definitely an > > improvement, but perhaps not quite the entire solution. > > Thanks for the feedback. The Ada compiler doesn't use libtool to build its > library so that's as expected (and import libraries are obsolete these days). That's not strictly true; while they may not be essential, import libraries are, by no means, obsolete. The search order, for the Windows linker[1], is: libfoo.dll.a foo.dll.a libfoo.a foo.dll libfoo.dll So, unless the foo.dll (or libfoo.dll) is in a different path from libfoo.a, and that path is searched earlier that the conventional lib path, then -lfoo will always cause static linking, if libfoo.dll.a is not provided. Also, when the static library is libfoo.a, and the DLL is qualified by a version suffix, -lfoo will never find libfoo-N.dll; this entirely defeats the linker's -Bdynamic vs. -Bstatic selection for -lfoo. A further problem with your DLL only convention is that the linker search path (normally) isn't anywhere that a running application will expect to find its shared objects, so we end up installing multiple copies of the DLL, spread around the file system. MinGW convention is to provide libfoo.dll.a and libfoo.a, in the linker search path, with foo-N.dll (or libfoo-N.dll) in the runtime path. [1]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html