How do I point out OS includes? -- Or how to Build My Own SDK using Newlib

[Anders Lindgren]

     Thanks for your detailed answer. I can sense the frustration you've gone 
through learning all this -- I've certainly felt quit a bit of it over the 
years, learning this stuff mostly by trial and error. :-)

     I agree on most of your points, it's quite similar to what I typically 
do.

     Yes, I am working with custom OSes, for embedded systems. The situation 
is typically this:

- A complete toolchain is packaged somewhere (by me), and people just 
install it and add it to their $PATH. The command line challenged crowd 
gets a "build_prompt.bat" file to click on, in the Wintendo case. ;-) 
Moving it around is no problem because gcc etc finds its own includes, 
libs and binaries relative to itself.

- The OS and the rest of the firmware source code is checked out of some 
version control system, and can be located just about anywhere on a user's 
hard disk. The firmware's build system uses an environment variable 
($ROOT, say) and *everything* is referenced relative (under) this top 
directory -- except the toolchain, which just needs to be in $PATH 
somehwere. In practice, the toolchain is in a standard place, too.

     Up until now, building these cross-toolchains have been simple enough 
that I never felt a need to try things like crosstool. I've traditionally 
just:

- Added my target to binutils, gcc and newlib configurations. Normally 
this only requires some trivial changes to config.sub, config.gcc and 
configure.host in newlib, plus a libc/sys/foo dir for my target for the 
syscalls, if any.

- Built and installed binutils configured as --target=foo-bar-baz 
--prefix=/my/tool/dir --program-prefix=foo- # Shorter to type.

- Soft-linked foo-bar-baz-$file to all of binutils' foo-$file (because gcc 
is too stupid to guess that if I'm building it with program-prefix=foo, 
binutils might just have been, too).

- Soft-linked newlib-v.w.0/newlib into gcc-x.y.z/, and built the lot.

     The configure/build/install part of this I typically put in a script and 
just go.

     This has worked fine for a couple of years, because at first no syscalls 
were used in my newlib and, when I first started integrating stdio 
support, I got away without overriding any newlib headers. So the new 
thing here is really just that my target has ended up needing to provide 
it's own version of sys/lock.h -- which now depends on OS headers. These 
are of course located not in a fix location, but somewhere under $ROOT, 
wherever that is.

     Maybe --with-sysroot + some symlinks would've accomplished what I ended 
up doing: I built using --with-headers=$ROOT/foo/include, installed 
everything, and then rm -rf'd $prefix/foo-bar-baz/sys-include/*. Since the 
toolchain is only used within (or in combination with) the firmware build 
system, there'll always be a -I pointing out the OS includes. While 
changes to those OS includes (admittedly rare) may very well mean I need 
to rebuild newlib, I _don't_ want to keep non-versioned copies of them 
inside the gcc tree.

     I had to disable libssp (its configure appeared to try to execute a 
_target_ binary after a GCC_NO_EXECUTABLES token, or somesuch) and 
libstdc++ (which had complaints about no native atomic operations being 
available), but I didn't look further into either since I don't actually 
use them.

     Hrrm, I've written a rather detailed HOWTO of this whole procedure (for 
my own memory), and with these include issues more or less figured out, 
I'd say it's quite complete. I think I'll update it with notes on target 
includes and put it on the web -- it should be a good tutorial for 
beginners. I'd appreciate all feedback if any of you care to read it when 
it's up.

Regards,
ali:)