> Based on this discussion:
> I think it would be a good idea to add a compiler switch to select the
> runtime library. If the "-mcrtlib=<name>" switch is not feasible to do
> specs then "-mmsvcr71" should be good enough. For the headers, do you
> to just add the new functions unconditionally so that a link error
> you use __aligned_malloc() but don't use -lmsvcr71? (Sounds okay to me
> it's worth mentioning)
On second thought....
Getting a switch into gcc driver to tell it which version of MS CRT
to use is not going to be pretty. Particularly if we want to
keep our options open for msvcr72.dll, msvcr80.dll,etc,
This is how I handle msvcr71.dll while I have been testing it:
cp -f /mingw/lib/libmsvcr71.a /mingw/lib/msvcr71/libmsvcrt.a
gcc -L/mingw/lib/msvcr71 foo.c
So I always link against libmsvcrt.a as per specs but I use the alt
version, specified by library search path.
I would prefer to simplify mingw's gcc specs rather than making it
even harder to maintain. Compare mingw's GCC_SPEC and LIB_SPEC
with that of other targets, So what I'm really saying is that
a patch to GCC to add -mmsvcr71 or -mcrtlib=<name> is not high priorty
Modifying msvcr71.def to get the new symbols in is more important right
as is how to guard the declarations in headers.
RE: __aligned_malloc. Perhaps we should add __mingw_aligned_malloc and
friends (using the patsch submitted awhile back) to libmingwex and allow
the user to
define __aligned_malloc __mingw_aligned_malloc #ifndef __MSVCR71__.