#362 Make mingwex a DLL so other DLLs can depend on it


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


  • Jeff Bonggren

    Jeff Bonggren - 2003-06-01

    mingwex dll patch

  • Earnie Boyd

    Earnie Boyd - 2004-02-24

    Logged In: YES


    What do you think about this?


  • Earnie Boyd

    Earnie Boyd - 2004-02-24
    • priority: 5 --> 8
    • assigned_to: earnie --> dannysmith
  • Jeff Bonggren

    Jeff Bonggren - 2004-02-25

    Logged In: YES

    Since I posted this bug I've been working on building up a
    set of libraries for cross builds using w32api, mingw, glib,
    gtk, etc. In the process, I found more functionality that
    was built into static libs and not dlls. I had to make
    similar changes in these cases. Specifically, I had to do
    this to several libraries in w32api.

    Because the existing mingw/w32api naming scheme had no way
    to distinguish between static libs and dll import libs and
    because I had already broken compatibility, I went ahead
    and changed the library naming convention for mingw and
    w32api to that of libtool-1.5 like I described in the
    original report.

    In addition, I took advantage of newer versions of binutils
    that build dlltool-like functionality into ld and removed
    much of the dll-building complexity from the makefiles
    without making the leap to libtool and/or automake.

    I hadn't bothered posting patches due to the fairly large
    changes they would bring, and due to a percieved lack of
    interest here.

    Since I see that someone is reading these bug/feature
    reports, I figured I might as well post a more complete and
    up-to-date patch and see what happens.

    I would be happy to provide my similar (and somewhat more
    drastic) w32api patch as well if there is any interest.


  • Jeff Bonggren

    Jeff Bonggren - 2004-02-25

    mingw 3.1 dll/build/naming patch

  • Jeff Bonggren

    Jeff Bonggren - 2004-02-25

    w32api 2.4 dll/build/naming patch

  • Danny Smith

    Danny Smith - 2004-02-25

    Logged In: YES

    Re: libmingwex as dll.
    I disapprove of the proposal to create a libmingwex.dll.a and
    install it in a system directory. This will make the dll version of
    libmingwex the default (ld gives libfoo.dll.a higher priority than
    libfoo.a when searching for -lfoo). Hence, by default, an app
    that links against libmingwex will require redistribution of
    libmingwex.dll. This will surprise many users who do not
    expect or want this behaviour. Perhaps, if the import lib was
    renamed, say, libmingwex_so.dll.a, then the libmingwex dll
    could co-exist with the static lib without upsetting current
    default behaviour.

    A libmingwex.dll will need some kind of dllimport macro in
    getopt.h for the exported data symbols (optarg, opterr,
    optind, optopt, optreset).

    The problem of using static libmingwex.a functions in dll is a
    libtool problem. From the command line, it is quite easy to
    create a dll that uses these functions (just as it is quite
    easy -- but not necessarily efficient -- to create a C++ dll
    that uses libstdc++.a functionality)

    Re: renaming of existing import libs

    Renaming of libmsvcrt.a (and friends) and the w32api import
    libs to *.dll.* 's will cause some inconvenience when users
    update their current toolset to the new naming scheme: The
    old libfoo.a libs will probably need to be removed to prevent
    duplication and confusion. But this may cause problems if
    projects use explicit full names in naming their library's (eg
    they have a --library libws2_32.a on their command line).

    The w32api changes will also affect cygwin users.

    I don't know how this will affect Watcom, which also uses the


  • Earnie Boyd

    Earnie Boyd - 2004-02-25

    Logged In: YES


    1) This is a feature request and not a Bug.
    2) The Cons in our opinion out weigh the Pros.


  • Earnie Boyd

    Earnie Boyd - 2004-02-25
    • assigned_to: dannysmith --> earnie
    • status: open --> closed-rejected
  • Earnie Boyd

    Earnie Boyd - 2013-01-24
    • labels: mingw runtime (deprecated use WSL) -->
    • status: closed-rejected --> closed
    • resolution: --> rejected
    • category: --> Feature_requests
    • milestone: Feature_requests --> WSL

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks