Using newlib 2.1.0 headers with clang

[ed@nelson305.com]

Hello,

After upgrading to newlib 2.1.0, compiling a test project fails when using
clang as follows:

clang -emit-llvm -c -o "newlib_stubs.c.bc" -target thumbv7-none-eabi
-mcpu=cortex-m3 -mthumb -mfloat-abi=soft -I"." -I"../source"
-I"../si32-1.1.2/si32Hal/sim3l1xx" -I"../si32-1.1.2/si32Hal/SI32_Modules"
-I"../si32-1.1.2/si32Hal/CPU" -I"/usr/lib/gcc/arm-none-eabi/4.7.3/include"
-I"/usr/arm-none-eabi/include"  -Wall -g -O0 -fmessage-length=0
-fno-builtin -ffunction-sections -fdata-sections -std=c99 
"../source/newlib_stubs.c"
In file included from ../source/newlib_stubs.c:3:
In file included from ../source/newlib_stubs.h:4:
In file included from /usr/arm-none-eabi/include/sys/stat.h:9:
In file included from /usr/arm-none-eabi/include/time.h:11:
In file included from /usr/arm-none-eabi/include/sys/reent.h:15:
In file included from /usr/arm-none-eabi/include/sys/_types.h:12:
In file included from /usr/arm-none-eabi/include/machine/_types.h:7:
/usr/arm-none-eabi/include/machine/_default_types.h:28:9: error: unknown
type name '__UINT8_TYPE__'
typedef __UINT8_TYPE__ __uint8_t;
        ^
/usr/arm-none-eabi/include/machine/_default_types.h:38:9: error: unknown
type name '__UINT16_TYPE__'
typedef __UINT16_TYPE__ __uint16_t;
        ^
/usr/arm-none-eabi/include/machine/_default_types.h:56:9: error: unknown
type name '__UINT32_TYPE__'
typedef __UINT32_TYPE__ __uint32_t;
        ^
/usr/arm-none-eabi/include/machine/_default_types.h:78:9: error: unknown
type name '__UINT64_TYPE__'
typedef __UINT64_TYPE__ __uint64_t;
        ^
/usr/arm-none-eabi/include/machine/_default_types.h:169:9: error: unknown
type name '__UINTPTR_TYPE__'
typedef __UINTPTR_TYPE__ __uintptr_t;
        ^
5 errors generated.

With newlib 2.1.0, the project builds using gcc.  Looking at the CVS
commit logs for newlib/libc/include/machine/_default_types.h, I found that
the typedefs for __int8_t, __int16_t, ... use built-in macros supplied by
the compiler.  The header assumes that if a define for a signed type
exists then the define for the unsigned type exists as well.  This is true
for gcc but not for clang.

The attached patch allows successful compilation with clang.  It uses
unsigned type defines where they exist and falls back to using signed type
defines with the unsigned keyword.

Regards,

Ed Nelson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newlib-no-uint-type-defines.diff
Type: application/octet-stream
Size: 3120 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20140303/d5d3f6d3/attachment.obj>