I have run into problems compiling other DLLs that
require C99 functionality on mingw32. The problem is
that (as far as I know) a DLL can't depend on a static
archive because all symbols must be resolved at link time.
On UNIX this is not the case and shared objects can
depend on static archives to be linked in by the
executable that uses the shared object.
Most features in mingw are exported via a DLL import
library built to point to a MS dll in the runtime
environment. Functionality added by mingw such as
libmingwthrd is also put into a DLL.
The only functionality not in a DLL is libmingwex. I
was trying to build a DLL that requires C99 features
and was unable to do so because libmingwex (required
for C99 features) was unavailable as a DLL. Libtool
complains it can't find a DLL or import library.
To fix this, I have modified the mingw-runtime Makefile
to build a static archive, a DLL, and an import library
for libmingwex. It borrows the dlltool weirdness from
the build of the libmingwthrd DLL.
I used a different naming convention for this DLL than
was used for libmingwthrd. I used the naming
convention of libtool-1.5 that says that the libfoo.a
is the static archive, libfoo.dll.a is the import
library and libfoo-version.dll is the DLL.
This works well in my cross compile environment on
Linux but perhaps the abbreviated naming convention for
libmingwthrd was done for a reason. If this is so, the
mingwex name should be similarly abbreviated.
I am attaching the patch here. The patch is against