Ingo Weinhold wrote: > On 2012-08-02 at 22:49:23 [+0200], mmadia-github.separate-build-environment > <community@xxxxxxxxxxxx> wrote: > > diff --git a/headers/build/posix_target/target_limits.h > > b/headers/build/posix_target/target_limits.h > > index 138fd32..deb1463 100644 > > --- a/headers/build/posix_target/target_limits.h > > +++ b/headers/build/posix_target/target_limits.h > [...] > > -#include <float.h> /* for DBL_DIG, FLT_DIG, etc */ > > +// TODO: #8730 -- create header from build/gcc-2.95.3/float.h > > +#include <gcc-2.95.3_target/target_float.h> /* for DBL_DIG, > > FLT_DIG, etc */ > > No, that's not the right one. I don't recall why we have the gcc 2 headers in > the repository anyway, but there probably is a reason. Anyway, those should > not be mirrored or used in headers/build at all. With compiler headers I mean > the headers belonging to/provided by the compiler used. I.e. in this case > it's the build platform compiler. Its header directory depends on how and > where it is installed. > > gcc may have an option to print that directory (or those directories), so > theoretically our configure could get that directory and it might be possible > to include headers directly from there. That sounds relatively complicated > though, and I'm not sure whether it might have undesired side effects. > > The better alternative is to add the definitions needed to > HaikuHostBuildConfig.h. You'd need to add a little program (with a purpose > analogous to that of test_int_types.cpp, but different implementation). If > you only have macros, it would look like: [...] I just notice that <float.h> is a pure compiler header, i.e. doesn't have an equally named wrapper provided by the OS (hopefully on all our host platforms). So you can included it directly (like <stdarg.h> and <stdbool.h>) as before and remove target_float.h and float.h from headers/build/.... Sorry for the confusion. What I wrote with respect to adding stuff to HaikuHostBuildConfig.h holds for the compiler's <limits.h>, though. CU, Ingo