Building with Clang trunk on Mac OS X

Andrzej had asked about it on IRC yesterday, so here is my how-to 
building LO master with a self-built Clang trunk (so one can use our 
Clang plugins) on current Mac OS X 10.11.4 with current Xcode 7.3:

* My relevant autogen.input lines are:

> --with-macosx-sdk=10.11
> --with-macosx-version-min-required=10.11
> CC=/Users/stephan/Software/llvm/inst/bin/clang -m64 -mmacosx-version-min=10.11 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk 
> -fdiagnostics-color
> CXX=/Users/stephan/Software/llvm/inst/bin/clang++ -m64 -stdlib=libc++ -mmacosx-version-min=10.11 
> -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk 
> -isystem 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 
> -fdiagnostics-color
> CLANGDIR=/Users/stephan/Software/llvm/inst
> COMPILER_PLUGINS_CXX=clang -fdiagnostics-color

** The -m64 and -stdlib=libc++ switches in the CC/CXX command lines are 
taken from what configure.ac would have determined automatically for the 
"use the normal compiler" case a long time ago, and then just kept 
there.  It may no longer be strictly necessary to pass them explicitly.

** I am arbitrarily using 
--with-macosx-version-min-required=10.11/-mmacosx-version-min=10.11. 
Probably works just as well (or maybe even better, see below) when 
targeting an older minimum version.

** The given paths of course depend on where you install Xcode and 
Clang, respectively.

** -fdiagnostics-color is just because I tend to use "make -O".

* For reasons unclear to me, my builds recently started to fail when 
linking certain external projects.  The common theme is that those 
external projects use libtool, libtool calls ld with -flat_namespace, 
and some libraries are not found without the help of explicit 
-dylib_file hints.  Other people seem unaffected by this, and I'm not 
sure what part of my setup is the root cause for this.  But my 
workaround patch for now is:

> diff --git a/external/firebird/ExternalProject_firebird.mk 
> b/external/firebird/ExternalProject_firebird.mk
> index cd89dfb..a4ed4b9 100644
> --- a/external/firebird/ExternalProject_firebird.mk
> +++ b/external/firebird/ExternalProject_firebird.mk
> @@ -50,13 +50,14 @@ $(call gb_ExternalProject_get_state_target,firebird,build):
>                 && export CXXFLAGS=" \
>                         $(if $(SYSTEM_BOOST),$(BOOST_CPPFLAGS), \
>                                 -I$(call gb_UnpackedTarball_get_dir,boost) \
> -                               -L$(call gb_UnpackedTarball_get_dir,boost)/source/lib \
>                         ) \
>                         $(if $(SYSTEM_ICU),$(ICU_CPPFLAGS), \
>                                 -I$(call gb_UnpackedTarball_get_dir,icu)/source \
>                                 -I$(call gb_UnpackedTarball_get_dir,icu)/source/i18n \
>                                 -I$(call gb_UnpackedTarball_get_dir,icu)/source/common \
>                                 -L$(call gb_UnpackedTarball_get_dir,icu)/source/lib \
> +                               $(if $(filter MACOSX,$(OS)),$(foreach lib,data i18n uc, \
> +                                       
> -Wl$(COMMA)-dylib_file$(COMMA)@__________________________________________________OOO/libicu$(lib).dylib.57:$(call
>  gb_UnpackedTarball_get_dir,icu)/source/lib/libicu$(lib).dylib.57)) \
>                         ) \
>                         " \
>                 && MAKE=$(MAKE) ./configure \
> diff --git a/external/redland/ExternalProject_redland.mk 
> b/external/redland/ExternalProject_redland.mk
> index 64746ff..52fc982 100644
> --- a/external/redland/ExternalProject_redland.mk
> +++ b/external/redland/ExternalProject_redland.mk
> @@ -46,7 +46,8 @@ $(call gb_ExternalProject_get_state_target,redland,build):
>                 CFLAGS="$(CFLAGS) $(if $(filter TRUE,$(DISABLE_DYNLOADING)),-fvisibility=hidden)" \
>                 LDFLAGS=" \
>                         $(if $(filter LINUX FREEBSD,$(OS)),-Wl$(COMMA)-z$(COMMA)origin 
> -Wl$(COMMA)-rpath$(COMMA)\\"\$$\$$ORIGIN") \
> -                       $(if $(SYSBASE),$(if $(filter LINUX SOLARIS,$(OS)),-L$(SYSBASE)/lib 
> -L$(SYSBASE)/usr/lib -lpthread -ldl))" \
> +                       $(if $(SYSBASE),$(if $(filter LINUX SOLARIS,$(OS)),-L$(SYSBASE)/lib 
> -L$(SYSBASE)/usr/lib -lpthread -ldl)) \
> +                       $(if $(filter 
> MACOSX,$(OS)),-Wl$(COMMA)-dylib_file$(COMMA)@loader_path/libraptor2-lo.0.dylib:$(INSTROOT)/$(LIBO_LIB_FOLDER)/libraptor2-lo.0.dylib)"
>  \
>                 CPPFLAGS="$(if $(SYSBASE),-I$(SYSBASE)/usr/include)" \
>                 PKG_CONFIG="" \
>                 RAPTOR2_CFLAGS="-I$(call gb_UnpackedTarball_get_dir,raptor)/src" \

* Also, for reasons unclear to me, "make check" often fails when during 
JunitTests soffice crashes in what smells like threading violations in 
using the system's GUI APIs.  Again, other people seem unaffected by 
this, and I'm not sure what part of my setup is the root cause for this.