Get the default include paths from Clang

When porting our code to build for Win32 with Clang, on macOS, I got a bunch of intrinsics errors:

/usr/local/opt/llvm/bin/lld-link: error: dlib.lib(image_2.o): undefined symbol: __cpuid

/usr/local/opt/llvm/bin/lld-link: error: dlib.lib(image_2.o): undefined symbol: _mm_setr_epi16

/usr/local/opt/llvm/bin/lld-link: error: dlib.lib(image_2.o): undefined symbol: _mm_set1_epi32

/usr/local/opt/llvm/bin/lld-link: error: dlib.lib(image_2.o): undefined symbol: _mm_load_si128

This error is a bit unusual (for me at least) so it threw me off, since I had obviously linked against the dlib.lib before, only difference, it was using CL.exe at that time.

This isn't due to a missing library, but in fact a missing include.
And as it turns out, the order of includes.

The compiler checks the include file(s) to see what symbols to put in there, and if it recognises it, it outputs the correct intrinsic function in the code. Otherwise, it's unresolved, and will later become undefined.

And, in order to make the code a bit more resilient towards compiler version updates, I wanted to grep the include paths in a simple fashion on both OSX/Linux:

macOS:

$ /usr/local/opt/llvm/bin/clang++ -Wp,-v -x c++ - -fsyntax-only < /dev/null 2>&1 | grep -e /clang

 /usr/local/Cellar/llvm/6.0.1/lib/clang/6.0.1/include

Linux:

$ clang++ -Wp,-v -x c++ - -fsyntax-only < /dev/null 2>&1 | grep -e /clang

 /usr/local/lib/clang/6.0.0/include

Compile cctools for Windows

I wanted to try building cctools for Windows,

I first tried (and failed) with cctools-port
Next, I tried (and succeeded) with osxcross and Cygwin (32 and 64 bit).

Also note that I needed no iOS/OSX SDK for this!

Here's a brief recap on what I had to do...

Memory allocation debugging

Sometimes it's beneficial to see the actual memory allocations done by an app, but you don't want to code a full memory allocation system. Perhaps you cannot even rebuild the app.

Then a good option is to use a dynamic library to override all the allocation functions.

The idea is simple, make sure the application finds your library before any other, and let it use the custom malloc-functions. Here is the source

On MacOS, you'll use

    $ DYLD_INSERT_LIBRARIES=libmemprofile.dylib ./a.out

and on Linux:

    $ LD_PRELOAD=libmemprofile.so ./a.out

The result will look like this:

$ DYLD_INSERT_LIBRARIES=libmemprofile.dylib ./a.out

Memory used: 

   Total: 512 bytes in 2 allocation(s)

   At exit: 0 bytes in 0 allocation(s)