Re: [Mingw-users] Linking against MSVCR71.DLL

[Brian Dessent <brian@xxxxxxxxxxx>]

wilson1442@xxxxxxxxxxxxx wrote:

> As I'm sure you know, Billy, etal., insists no linking against
> MSVCRT.DLL and advise MSVCR71.DLL instead.  By default, MinGW is naughty
> and wants to link against the forbidden library.

Just for the record: There are very good reasons to only target
MSVCRT.DLL.  For one, it is the only one that is guaranteed to exist on
Windows.  In all other cases, you must make provisions to distribute the
library along with your program.  Whether you are allowed to distribute
this DLL with your software is unclear if you do not own a license to MS
Visual Studio.

Furthermore, it may consitute a license violation of the GPL if you were
to link GPL code to MSVCR71.DLL because it would be creating a combined
work that is not GPL.  The only reason that this is permissable when
linking to MSVCRT.DLL is that the GPL contains an exception clause for
"components of thee operating system" which MSVCRT is but the other
versions are not.

> I'm using MinGW 3.4.2 built as a cross-compiler. In the .../3.4.2/specs
> file, I changed "... -lmsvcrt" to "... -lmsvcr71", and it *almost*

BTW, you can also do this without touching the specs file: run the link
command with -###, copy and paste the command that would have been run
but change both occurances of -lmsvcrt to -lmsvcr71.

> In case my libraries were stale, I rebuilt both mingw-runtime-3.10 and
> w32api-3.1 with the changed specs file, but no joy.  I've attached some
> test code that illustrates the problem.

Er, those are very old versions.  mingw-runtime 3.10 is about a year and
a half old (current is 3.14) and w32api 3.1 is about 3.5 years old
(current is 3.11). 

> Any help would be appreciated.

The problem is libmoldname.  As you might know, the MS runtime spells
stat as _stat and so on.  This library is just a convenience to provide
aliases so that programmers who are used to not using the underscore can
continue to do so.  But libmoldname acts as an import library to
MSVCRT.DLL, and that is where the dependance is coming from.  To make
this work you will need to either use the underscored version of the
functions, or rebuild libmoldname so that it targets the desired version
of the runtime.  Doing this is simple enough, if you look in Makefile.in
you will see:

libmoldname.a: moldname-msvcrt.def $(MOLD_OBJS)
        $(DLLTOOL) --as $(AS) -k -U     \
                --dllname msvcrt.dll    \
                --def moldname-msvcrt.def       \
                --output-lib $@
        $(AR) rc $@ $(MOLD_OBJS)
        $(RANLIB) $@

So, it looks like we need to ship multiple versions of libmoldname, to
match the versions of the runtime, e.g:

libmoldname.a   & libmsvcrt.a
libmoldname70.a & libmsvcr70.a
libmoldname71.a & libmsvcr71.a
libmoldname80.a & libmsvcr80.a

Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users