Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Danny Smith <dannysmith-oKK1aGe2n869koe0gwxAeg <at> public.gmane.org>
Subject: Re: Re: Released: MinGW-3.1.0-1.exe
Newsgroups: gmane.comp.gnu.mingw.user
Date: Tuesday 16th September 2003 09:19:33 UTC (over 14 years ago)
----- 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=)
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.
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MinGW-users mailing list
[email protected]

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