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

[Jeff Bonggren]

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
mingw-runtime-3.0.

[Jeff Bonggren]

mingwex dll patch

[Earnie Boyd]

Logged In: YES
user_id=15438

Danny,

What do you think about this?

Earnie

[Jeff Bonggren]

Logged In: YES
user_id=709953

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.

Regards,
Jeff

[Jeff Bonggren]

mingw 3.1 dll/build/naming patch

[Jeff Bonggren]

w32api 2.4 dll/build/naming patch

[Danny Smith]

Logged In: YES
user_id=11494

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
w32api.

Danny

[Earnie Boyd]

Logged In: YES
user_id=15438

REJECTED.

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

Earnie.