Target include woes

[Anders Lindgren <ali at df dot lth dot se>]

  (Sorry if this is effectively a cross-gcc question, but since it's 
directly newlib related I expect the expertise on the subject is here)

  I am trying to (re)build my "native" cross-toolchain using newlib 1.14.0 
after fixing some bugs in my target's syscall glue, but now my new syscall 
glue requires some target OS includes I'd rather not just copy into 
newlib's tree. Adding a -I option to my target's $newlib_cflags in 
configure.host does the trick for building the newlib multilibs (built 
automagically by the gcc build) themselves. But then after the gcc build 
has built libstdc++v3, it tries to build a target libiberty, and fails 
miserably since it ends up #include:ing my target OS includes (e.g. via 
newlib's <sys/lock.h>, which my newlib target supplies a custom version 
of) without having any include path to those directories.

  It's a freestanding embedded target, so those target includes could be 
anywhere the user decides to check out the source tree. Hence I don't want 
to end up with any such build-time include path built into the compiler, 
if avoidable. They'll be automatically supplied by the user's target build 
system.

  This sounds like a pretty typical situation for a newlib-gcc build, so I 
am thinking there must be some official Right Way(tm) of adding a target 
include path while building the cross-target libraries.

  I tried setting --with-sysroot=<dir> in the top-level gcc configure 
invocation, but I never noticed it having any effect; specifically, that 
libiberty-for-target build had no such path on the xgcc command-line (nor 
the include-path I put into $newlib_cflags in configure.host).

  I'd be very happy if someone could explain the correct way of doing 
this (or alternatively, what I should be doing instead :-) ).

Best regards
Anders "ali" Lindgren