This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: How do I point out OS includes? -- Or how to Build My Own SDK using Newlib
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:)