Re: [Mingw-users] Re: Released: MinGW-3.1.0-1.exe

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

----- Original Message -----
> From: "Moore, Paul"
> From: Danny Smith
> >> Note that malloc comes from msvcr71 and free from msvcrt. Surely
> >> that's going to cause a problem??! (I'm not on a PC with
msvcr71.dll
> >> installed at the moment, so I can't check for sure...)
> >
> >
> > Ouch.
> >
> > The problem is that free and abort are referenced from libgcc.a
(from
> > w32-shared-ptr.o) which comes _after_ your command line -lmsvct71.
>
> > I think the only ways to fix it are
> [...]
> > 3) add dummy references to free and abort in your code (or in crt2.o
> > startup code).
>
> In practice, this is probably OK. For real-world use, you're not
likely
> to find code which references malloc but not free. I'm not so sure
about
> abort, but a dummy call isn't hard.
>
> > For the nonce, I would just not use -lmsvcr71.
>
> Either of these options are fine for the moment. My interest is in
> building DLLs which can interoperate with an existing application
> which was built with MSVC7. It's a longer term issue, as at present
> the application (the Python interpreter) is still built with MSVC6,
> but at some point, the intention is to switch to MSVC7, and I'd like
> to ensure that it's still possible to build extensions with Mingw when
> that happens.
>
> In the longer term, is there likely to be a more transparent fix, or
> is this just going to be one of the things people must be aware of?
>

There are other potential problems:

eg -lmsvcr71d -lfoo. If libfoo.a references CRT functions
they would be resolved by msvcrt.dll, not msvcr71d.dll.
So, we would have to remember that "order matters"
for runtime libs as well as for w32api libs.

What might work is a compiler switch (say -mcrtlib=<dllname>)
that makes one of the following libs the last one specified
in LIBGCC_SPEC

libcrtdll.a
libmsvcrt.a
libmsvcrtd.a
libmsvcr70.a
libmsvcr70d.a
libmsvcr71.a
libmsvcr71d.a

with libmscvrt.a the default.

The same switch could also be used to control crt startup objects,
(which would help fix a related bug with malloc/atexit/dllonexit)

I'm testing the first cut at patch to gcc now, so it might be ready by
gcc-3.4.
.
Danny

> Paul.
>