OSDev.org

I've been porting newlib recently, and so far have been succesfull.

However, I am currently trying to recompile the entire toolchain, which has been made aware of my OS, to work in a sysroot environment. So far, i have done the following steps:

Compile binutils with --with-sysroot=/path/to/sysroot
Compile temporary gcc with --without-headers (and hence without --with-sysroot, as that overides the --without-headers and causes trouble)

I was planning my next step to be to compile newlib using --with-sysroot=/path/to/sysroot, and then recompile gcc to both make use of the c library and be sysroot aware. However, when trying to compile newlib, it is not using the /usr/include directory. This is a problem, as that is where I installed (and want to install) the headers my kernel exports. I have tried to force it to also use that directory as an include directory by adding CPPFLAGS=-I/path/to/sysroot/usr/include to both the configure step and to the make step, but this doesn't seem to do much.

I am now left with two questions: Why is the include directory not picked up in the first place? Has anybody experience with a solution for this?

May be try "-isysroot /path/to/sysroot" or "--sysroot=/path/to/sysroot" (in CPPFLAGS).

When you say it doesn't use the kernel headers, do you mean that it picks up the platform supplied ones (from the host OS) instead, or you mean that it fails to find any at all.

If you happen to have the gcc line that fails, you could substitute the -c with something like "-E -Wp,-v" and dig through the output.

Tried those variations just now, and they don't change anything either. What is more troublesome, is that CPPFLAGS doesn't really seem to change the compiler command. It seems newlib is isolating its build process pretty well from stray flags declarations.

As to the kernel headers, it definitely isn't picking them up where I supply them. Because I don't use the same name for these as my host os (linux in this case), I can't tell whether it is picking up the host kernel headers, but judging from the compile line the make file is printing I would doubt it can pick up stuff from there. I've included said line below:



From what I see here, I'm guessing that, for some reason, the newlib build system doesn't introduce --sysroot or -isysroot flags to the compiler, even though I'm telling it that it should compile in a sysroot-aware fashion. I wonder why it is ignoring that.

You probably already "export" the CPPFLAGS variable. Assuming that you use an environment variable and not a make command line variable assignment.

Aside from that, I noticed that in the automake source here there is a comment which I do not understand per se:
This variable, for some reason, tries to force recursive make command line variable assignments from environment variables. I notice that CPPFLAGS is not between them, but CFLAGS is. May be try CFLAGS instead?

I actually did not export the CPPFLAGS variable, just added it on the command line. Exporting it first doesn't seem to change anything, and neither does switching to manipulating CFLAGS. Neither seems to be giving so much as a hint of manipulating the actual compilation commands given by the make file. It seems newlib is rather protective of it's build environment.

I decided to do some more digging on building gcc with a sysroot, instead of without, particularly into the --without-headers and --with-newlib options which LinuxFromScratch seems to be using to build gcc using a sysroot without having the c library ready. From the gcc documentation and mailing lists, it seems --without-headers doesn't do much in combination with --with-sysroot, as the latter should just override --without-headers. However, --with-newlib seems to disable some very specific libgcc functionality under the assumption that it is already provided by newlib. From what I can tell, although not its purpose, for current versions of gcc this seems to be enough to keep libgcc from pulling in headers from the standard library.

I tried out the combination of --with-sysroot --without-headers and --with-newlib and it did build gcc. I'm not certain it includes a completely functional libgcc, but it is enough to get newlib to build, which then allows building of a gcc that actually is configured correctly to use the c-library, and which does install a working libgcc.

I'm not completely happy with the above solution. The use of --with-newlib seems a bit too much like a hack for my liking, but I can't really argue with the results. However, if someone has (a suggestion for) a more elegant solution I would love to hear it.