[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	10/10/16 12:16:12

Modified files:
	cm3/m3-libs/m3core/src/C/Common/: CstdioC.c CstdlibC.c 
	                                  CstringC.c 
	cm3/m3-libs/m3core/src/Csupport/Common/: dtoa.h hand.c 
	cm3/m3-libs/m3core/src/runtime/WIN32/: RTOSc.c 
	cm3/m3-libs/m3core/src/runtime/common/: RTIOc.c RTMiscC.c 
	                                        RTUntracedMemoryC.c 
	cm3/m3-libs/m3core/src/runtime/ex_frame/: RTStackC.c 
	cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32C.c 
	cm3/m3-libs/m3core/src/unix/Common/: Uexec.c Uin.c Unetdb.c 
	                                     UnixC.c UnixLink.c 
	                                     Uprocess.c UtimeC.c Uuio.c 
	cm3/m3-libs/sysutils/src/: SystemC.c 

Log message:
	Remove the _DLL/_MT hacking that I had put in,
	which purported to let one set of object code
	link with either msvcrt.lib or libcmt.lib.
	
	Not a bad idea, not a bad implementation, but
	a bit on the unsupported side.
	
	If user really wants to use libcmt.lib, he should
	modify the config file and rebuild everything (esp. m3core).
	We should possibly make such a configuration in Hudson.
	We should possibly automatically multiply out compile/link
	for any directories that contain any C? And then build_standalone
	could imply libmt.lib. Not a bad idea, but unlikely to happen.