So anyone who has ever done windows dev will know about MS's crazy system where, by default, they produce object files that have an embedded CRT reference, and offer something like 8 different CRT's to choose from. Inevitably, you run into situations where linking different libraries with references to conflicting CRT's causes link problems, requiring options such as /NODEFAULTLIB and various other hacks and work-arounds.

With the DMD-Win64 implementation, it seems this catastrophe has finally made it into D :)

I'm seeing this:
  DMD inserts a hard reference to LIBCMT in object files.
  Phobos contains some C code; when built by the MS compiler, also contains
hard references to LIBCMT.

This needs to be addressed. I think the proper steps are as follows:
1) Phobos has a choice; either phobos should not reference a particular CRT
at all, or produce a suite of phobos libs that match the MSCRT libs.
Is there a reason to reference a particular CRT flavour in phobos? If not
(phobos will work with any CRT choice), then the correct solution would be
to not embed the reference in the object files by using the /Zl compile
option when building the C code that links into phobos.

2) Just like the MSC compiler options (/MT, /MTd, /MD, /MDd), DMD needs to
support a compiler option to select which CRT reference to embed in the
object files. It should probably also choose the debug runtime in -debug
builds by default.
Finally, it should also support an option equivalent to /Zl (Omit Default
Library Name), so object files can be produced with no hard reference.

This will give users the proper amount of flexibility WRT CRT linkage necessary when used alongside C/C++ projects, which is currently causing at least myself a bit of trouble.

On Sun, 09 Feb 2014 19:44:39 -0800, Manu <turkeyman@gmail.com> wrote:

> So anyone who has ever done windows dev will know about MS's crazy system
> where, by default, they produce object files that have an embedded CRT
> reference, and offer something like 8 different CRT's to choose from.
> Inevitably, you run into situations where linking different libraries with
> references to conflicting CRT's causes link problems, requiring options
> such as /NODEFAULTLIB and various other hacks and work-arounds.
>
> With the DMD-Win64 implementation, it seems this catastrophe has finally
> made it into D :)
>
> I'm seeing this:
>   DMD inserts a hard reference to LIBCMT in object files.
>   Phobos contains some C code; when built by the MS compiler, also contains
> hard references to LIBCMT.
>
> This needs to be addressed. I think the proper steps are as follows:
> 1) Phobos has a choice; either phobos should not reference a particular CRT
> at all, or produce a suite of phobos libs that match the MSCRT libs.
> Is there a reason to reference a particular CRT flavour in phobos? If not
> (phobos will work with any CRT choice), then the correct solution would be
> to not embed the reference in the object files by using the /Zl compile
> option when building the C code that links into phobos.
>
> 2) Just like the MSC compiler options (/MT, /MTd, /MD, /MDd), DMD needs to
> support a compiler option to select which CRT reference to embed in the
> object files. It should probably also choose the debug runtime in -debug
> builds by default.
> Finally, it should also support an option equivalent to /Zl (Omit Default
> Library Name), so object files can be produced with no hard reference.
>
> This will give users the proper amount of flexibility WRT CRT linkage
> necessary when used alongside C/C++ projects, which is currently causing at
> least myself a bit of trouble.

+1,000,000

I don't even care which of these options is chosen, but something would be better than silently forcing one. Because MS is silly. This document has more details about the options on Windows: http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

It should be noted that MS strongly recommends linking the Multithreaded Dynamic Link (msvcrt.lib/msvcrtd.lib) libraries by default.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator