[Bug ada/80921] cross compiling fails to build Ada shared libraries

["keith.marshall at mailinator dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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