Fix build with latest Xcode on OSX

[janvorli]

The latest Xcode 9 cannot successfully build CoreCLR PAL. There are
several issues. First, it complains that min / max macros cannot be defined
in C++ code, since they would collide with the std::min and std::max
functions. Second, some of the headers that PAL includes pull in declarations
of several template classes that we explicitly define in PAL and also
the new operator declaration.

To fix that, I have undefined the min and max macros for PAL and replaced
their usage by the std::min / max functions. I have also removed the manual
declaration of the colliding template classes and new operator and added
inclusion of the proper C++ headers instead.

The PAL was including non-pal safemath.h and to make this change compatible
with it, I have added definition of USE_STL that makes safemath.h include
type_trait from STL instead of our local trimmed copy.

I have also removed some dead code that I have discovered during the process.

Fixes #14279

[janvorli]

CC: @4creators

[janvorli]

All ARM legs are failing due to some C++ headers stuff. I need to look into it.

[4creators]

@janvorli

There are still errors on my local machine when building you PR (this could be outdated dependencies - pls advise):

In file included from /Users/uw/src/coreclr/tests/src/Exceptions/ForeignThread/ForeignThreadExceptionsNative.cpp:9:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/thread:97:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/__mutex_base:17:
/Library/Developer/CommandLineTools/usr/include/c++/v1/__threading_support:156:1: error: unknown type name 'mach_port_t'
mach_port_t __libcpp_thread_get_port();
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__threading_support:300:1: error: unknown type name 'mach_port_t'
mach_port_t __libcpp_thread_get_port() {
^
/Library/Developer/CommandLineTools/usr/include/c++/v1/__threading_support:301:12: error: use of undeclared identifier 'pthread_mach_thread_np'
    return pthread_mach_thread_np(pthread_self());
           ^
3 errors generated.
make[2]: *** [tests/src/Exceptions/ForeignThread/CMakeFiles/ForeignThreadExceptionsNative.dir/ForeignThreadExceptionsNative.cpp.o] Error 1
make[1]: *** [tests/src/Exceptions/ForeignThread/CMakeFiles/ForeignThreadExceptionsNative.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

End it ends at 34% with the following message:

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libcee_wks.a(jithelpers_slow.S.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libcee_wks.a(jithelpers_slow.S.o) has no symbols
[ 34%] Built target cee_wks
make: *** [all] Error 2
Failed to build CoreCLR component.

[janvorli]

@4creators this is really strange. Would it be possible for you to upgrade to the latest Xcode 9? It seems like there is something broken with your includes. Unfortunately, I am no expert on Xcode, so I don't know how it sets include paths etc. And it may be that 8.3.2 had some problem in it that doesn't occur on 8.3.3. that I was using before migrating to 9.

[4creators]

@janvorli

After upgrade to Xcode 9.0 build is OK excepto for some warnings.
Seems that may earlier update to Xcode 9.0 Command Line Tools messed up headers.

[janvorli]

@4creators good to hear that. As for the warnings, are these warnings from the native code build or the managed stuff build?

[4creators]

@janvorli Pls find all warnings below. They all come from native build.

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libtracepointprovider.a(tracepointprovider.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libtracepointprovider.a(tracepointprovider.cpp.o) has no symbols
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libtracepointprovider.a the table of contents is empty (no object file members in the library define global symbols)

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libcoreclrpal.a(unicode_data.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libcoreclrpal.a(context.S.o) has no symbols

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder_crossgen.a(debuglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder_crossgen.a(bindinglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder_crossgen.a(cdebuglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder_crossgen.a(debuglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder_crossgen.a(bindinglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder_crossgen.a(cdebuglog.cpp.o) has no symbols

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder.a(debuglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder.a(bindinglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder.a(cdebuglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder.a(debuglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder.a(bindinglog.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libv3binder.a(cdebuglog.cpp.o) has no symbols

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libbcltype.a(windowsruntimebufferhelper.cpp.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libbcltype.a(windowsruntimebufferhelper.cpp.o) has no symbols

/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libcee_wks.a(jithelpers_slow.S.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: libcee_wks.a(jithelpers_slow.S.o) has no symbols

ld: warning: could not create compact unwind for _JIT_Stelem_Ref__ObjIsInstanceOfNoGC_Helper: dwarf uses DW_CFA_same_value
ld: warning: could not create compact unwind for _JIT_Stelem_Ref__ArrayStoreCheck_Helper: dwarf uses DW_CFA_same_value

[janvorli]

@jkotas I've fixed the ARM32 build issue. It turned out to be two things - one was 32 bit build related and the other was due to the fact that the Tizen and Ubuntu 16.04 ARM32 rootfs use very recent GLIBCXX. The type_traits in that version of GLIBCXX cannot compile if the wchar_t is redefined like we do in PAL. I've looked for options to fix that and the cleanest one turned out to be to pre-include the type_traits in palinternal.h before including pal.h that redefines the wchar_t.