Re: [Mingw-users] Some changes needed to build a C++ program linked with runtime msvcr71.dll

[Danny S. <dan...@cl...>]

> -----Original Message-----
> From:  Nicolas Grilly
> Sent: Monday, 12 February 2007 4:22 p.m.
> 
> Hello all,
> 
> I'm trying to use MinGW to build C and C++ programs linked with
> runtime msvcr71.dll.
> 
> So, I've edited c:\mingw\lib\gcc\mingw32\3.2.4\specs and replaced
> "-lmoldname -lmsvcrt" by "-lmsvcr71".
> 
> After this change, I've succeeded in building a C program linked with
> msvcr71.dll (a very simple Hello World application). The executable
> runs smoothly. I've used Dependency Walker to check the executable is
> linked only with msvcr71.dll.
> 
> So, it's okay with C, but I have some difficulties building the same
> Hello World application in C++, linked with msvcr71.dll.
> 
> Here is the issues I've identified:
> 
> 1/ The standard C++ library calls functions fdopen, read, write and
> strdup. These functions, not preceded by an underscore, don't conform
> to the ANSI standard. This is why they are defined in moldname, a
> library containing non-ANSI functions. The problem is that the current
> Makefile builds only one version of moldname, a version linked with
> msvcrt.dll, not msvcr71.dll. Do you think it's possible to change the
> Makefile in order to build a version of moldname dedicated to
> msvcr71.dll? I've looked at the process transforming msvcrt.def.in in
> several versions of the library and I guess it's possible to do the
> same thing for moldname.def.in.

That sounds like a lot of messiess that will get messier over tme.
As an alternative we could  use asm specs in the headers to redirect foo
to _foo eg:

FILE* __cdecl	fdopen (int, const char*) __asm__ ("__fdopen");  

to avoid dependency on libmoldname

> 
> 2/ msvcrt.def.in exports the symbol _ctype. This symbol exists in
> msvcrt.dll, but it doesn't exist in msvcr71.dll. I propose we'll move
> the corresponding line of msvcrt.def.in a section delimited by a
> directive #if  !(__msvcr71__ || __msvcr71d__) ... #endif
> 

Sure.

> 3/ Sadly, the standard C++ library uses _ctype... But it seems the
> problem is located in file
> /libstdc++-v3/config/os/mingw32/ctype_noninline.h. It contains the
> following lines:
> 
>     // Information as gleaned from /mingw32/include/ctype.h.
>     // This should be in mingw's ctype.h but isn't in older versions
>     // Static classic C-locale table.  _ctype[0] is EOF
>     extern "C"  unsigned short  __declspec(dllimport) _ctype[];
> 
> Is there a way to replace that with something compatible with 
> msvcr71.dll?

I don't know. I suppose we could provide a local copy of the _ctype
table if all we want is C-locale.

Danny

> 
> I'm looking forward reading your advice about these issues.
> 
> Thanks a lot,
> 
> Nicolas Grilly