This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]