Trying to build clang with clang on Solaris 10 / x86

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…

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:

I’ve successfully built llvm+clang 2.8 with the gcc 4.5.1 toolchain:

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