[cfe-dev] Trying to build clang with clang on Solaris 10 / x86

[Douglas Gregor]

On Jan 11, 2011, at 4:14 AM, Joakim Johansson wrote:

> Hi,
> 
> Background:
> I’m trying to get __private_extern__ to work properly with clang on Solaris (as it causes problems with libdispatch portability).
> 
> One root reason is that the gnu toolchain seems to be broken in its support of ‘hidden visibility’ on Solaris, even though it is supported by the platform itself since a very long time back - thus I want to be able to use the native Sun ld rather than gld.
> 
> I’m a bit unsure how to get clang to invoke the native linker rather than falling back on using gcc for linkage as it currently seems to do, any pointers appreciated…

That's in the driver's toolchain support. You'll likely need to create a new toolchain definition for Solaris to make this happen.

> So to get to the problem here:
> 
> As a step to get a ‘standalone’ clang I wanted to do a bootstrap compile using gcc and then compile clang using clang, which unfortunately fails.
> 
> The first step succeeds nicely:
> 
> [snip]
> 
> Unfortunately this second build using clang fails:
> 
> —————————
> -bash-3.00$ gmake
> gmake[1]: Entering directory `/home/jocke/llvm/clang-bootstrap/build/lib/System'
> llvm[1]: Compiling Alarm.cpp for Release build
> llvm[1]: Compiling Atomic.cpp for Release build
> In file included from /home/jocke/llvm/clang-bootstrap/llvm/lib/System/Atomic.cpp:14:
> In file included from /home/jocke/llvm/clang-bootstrap/llvm/include/llvm/System/Atomic.h:17:
> In file included from /home/jocke/llvm/clang-bootstrap/build/include/llvm/System/DataTypes.h:59:
> /usr/include/inttypes.h:53:9: error: 'long wchar_t' is invalid
> typedef long    wchar_t;
>        ^
> 1 error generated.
> gmake[1]: *** [/home/jocke/llvm/clang-bootstrap/build/lib/System/Release/Atomic.o] Error 1
> gmake[1]: Leaving directory `/home/jocke/llvm/clang-bootstrap/build/lib/System'
> gmake: *** [all] Error 1
> -bash-3.00$ 
> —————————
> 
> The I can find the following nice note in /usr/include/inttypes.h:
> —————————
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> /* Inclusion of <stddef.h> breaks namespace, therefore define wchar_t */
> 
> /*
> * wchar_t is a built-in type in standard C++ and as such is not
> * defined here when using standard C++. However, the GNU compiler
> * fixincludes utility nonetheless creates it's own version of this
> * header for use by gcc and g++. In that version it adds a redundant
> * guard for __cplusplus. To avoid the creation of a gcc/g++ specific
> * header we need to include the following magic comment:
> *
> * we must use the C++ compiler's type
> *
> * The above comment should not be removed or changed until GNU
> * gcc/fixinc/inclhack.def is updated to bypass this header.
> */
> #if !defined(__cplusplus) || __cplusplus < 199711L
> #ifndef _WCHAR_T
> #define _WCHAR_T
> #if defined(_LP64)
> typedef int     wchar_t;
> #else
> typedef long    wchar_t;
> #endif
> #endif  /* !_WCHAR_T */
> #endif  /* !defined(__cplusplus) || __cplusplus < 199711L */
> —————————
> 
> Any ideas? Anyone who have successfully built clang w/ clang ?


The issue here is that the Solaris headers are depending on the exact value of __cplusplus to do the right thing w.r.t. wchar_t, but Clang (like GCC) defines __cplusplus to 1 in its normal mode of operation. The magic comment in that string is used by GCC's fixincludes mechanism, which is a rather horrible hack we won't be replicating in Clang. There should be another solution.

You might try building with "-ansi", which will (among other things) set __cplusplus to 199711L. Alternatively, we could consider giving __cplusplus the appropriate definition in the Solaris target. 

	- Doug