Make no-tcmalloc (really, non-base/allocator) builds work again,

(i.e. this is a plain vanilla build used when layers like base/allocator
are getting in the way of debugging)
and make sure they use msvcrt rather than libcmt
(libcmt is used to help shim malloc/free, but it gets
in the way of valgrind doing the same thing).

Sadly, this is now a gyp-time operation rather than a Configuration
option.

Had to remove hardcoded C prototype for _set_new_mode, 
as that caused link errors.

Also add variables win_{release,debug}_{Optimization,RuntimeLibrary}
to let the valgrind build override those settings.

Fix calling convention on _set_new_mode to match the
one in <new.h>

BUG=none
TEST=build with ~/.gyp/include.gypi set as described in comment in common.gypi, gclient runhooks, do release build, verify all exe's and dll's linked against msvcrt dll


Review URL: http://codereview.chromium.org/455037

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33719 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 4 deletions

diff --git a/base/allocator/generic_allocators.cc b/base/allocator/generic_allocators.cc
index 659a061..6ea36ec 100644
--- a/base/allocator/generic_allocators.cc
+++ b/base/allocator/generic_allocators.cc
@@ -48,10 +48,6 @@ void* operator new[](size_t size, const std::nothrow_t& nt) __THROW {
   return generic_cpp_alloc(size, true);
 }
 
-}  // extern "C++"
-
-extern "C" {
-
 // This function behaves similarly to MSVC's _set_new_mode.
 // If flag is 0 (default), calls to malloc will behave normally.
 // If flag is 1, calls to malloc will behave like calls to new,
@@ -63,6 +59,10 @@ int _set_new_mode(int flag) __THROW {
   return old_mode;
 }
 
+}  // extern "C++"
+
+extern "C" {
+
 void* calloc(size_t n, size_t elem_size) __THROW {
   // Overflow check
   const size_t size = n * elem_size;