2016q1 update can not be built on FreeBSD: something wrong with stdint.h

Asked by Lev Serebryakov

I'm maintainer of gcc-arm-embedded port for FreeBSD.

All previous versions didn't have any problems to be built on FreeBSD with all instructions from build-toolchain.sh script. gcc-arm-none-eabi-5_2-2015q4-20151219 could be built flawlessly, for example. I've converted script to Makefile, but it doesn't matter, as all steps are the same.

But latest update gcc-arm-none-eabi-5_3-2016q1-20160330 fails to built on first gcc stage, as there are some problems with gcc-provided "stdint.h". Here is compiler command line and error from it (I've replaced looooooong path prefixes with variables from build-toolchain.sh):

===============================
echo timestamp > libgcc_tm.stamp
$BUILDDIR_NATIVE/./gcc/xgcc -B$BUILDDIR_NATIVE/./gcc/ -B$INSTALLDIR_NATIVE/arm-none-eabi/bin/ -B$INSTALLDIR_NATIVE/arm-none-eabi/lib/ -isystem $INSTALLDIR_NATIVE/arm-none-eabi/include -isystem $INSTALLDIR_NATIVE/arm-none-eabi/sys-include -g -O2 -mthumb -march=armv8-m.base -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I$SRCDIR/gcc/libgcc -I$SRCDIR/gcc/libgcc/. -I$SRCDIR/gcc/libgcc/../gcc -I$SRCDIR/gcc/libgcc/../include -o cmse.o -MT cmse.o -MD -MP -MF cmse.dep -c -mcmse $SRCDIR/gcc/libgcc/config/arm/cmse.c
In file included from $BUILDDIR_NATIVE/gcc/include/arm_cmse.h:38:0,
                 from $SRCDIR/gcc/libgcc/config/arm/cmse.c:27:
$BUILDDIR_NATIVE/gcc/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory
compilation terminated.
$SRCDIR/gcc/libgcc/config/arm/t-arm:14: recipe for target 'cmse.o' failed
===============================

Host system have stdint.h (as /usr/include/stdint.h), but looks like cross-gcc is instructed to not use host headers files (which is right), but provided file ("$BUILDDIR_NATIVE/gcc/include/stdint.h") does something wrong!

stdint.h in question ("$BUILDDIR_NATIVE/gcc/include/stdint.h") looks like this:

===============================
#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
# undef __STDC_LIMIT_MACROS
# define __STDC_LIMIT_MACROS
# undef __STDC_CONSTANT_MACROS
# define __STDC_CONSTANT_MACROS
# endif
# include_next <stdint.h>
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif
===============================

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Lev Serebryakov
Solved:
Last query:
Last reply:
Revision history for this message
Andre Vieira (andre-simoesdiasvieira) said :
#1

Hi Lev,

What C-library are you using? We build our toolchain using newlib which comes with a stdint.h as is required by the C-standard.

Cheers,
Andre

Revision history for this message
Lev Serebryakov (blacklion) said :
#2

System C library is FreeBSD libc. It contains stdint.h, of course:

% ls /usr/include/stdint.h
/usr/include/stdint.h
%

But error is produced from "xgcc", which MUST NOT use system headers, because it is cross-compiler, as far as I understand! It builds for ARM target, why does it want HOST stdint.h? And here are "-isystem" arguments passed to it!

For build of toolchain I'm using newlib, provided in bundle, of course, but error occurs at "gcc-first" stage, before any newlib build.

Revision history for this message
Lev Serebryakov (blacklion) said :
#3

I could attach full build log (binutils & everything), but it is 25MB. I could provide any config.log's and other files too, of course.

Revision history for this message
Andre Vieira (andre-simoesdiasvieira) said :
#4

What make command are you using to make gcc-first? As far as I know it should not be building libgcc for gcc-first.

Revision history for this message
Lev Serebryakov (blacklion) said :
#5

Ooooops, my fault! Looks like copy'n'paste error, which doesn't cause any harm in previous versions. Thank you!