[Toolchain] Competition between GCC's and Newlib's limits.h

[karuon]

Hi,

After reading the tutorial http://wiki.osdev.org/OS_Specific_Toolchain on the Wiki, I have built a custom toolchain for my OS including Binutils 2.23.2, GCC 4.8.1 and Newlib 2.0.0.

It is working quite well, except one point (well, as far as I know): when I include "limits.h" header from a source file, it includes that of GCC (/usr/local/cross/lib/gcc/i586-pc-myos/4.8.1/include-fixed/limits.h) instead of that of Newlib (/usr/local/cross/i586-pc-myos/include/limits.h). I could check it by adding #error preprocessing directives at the beginning of both header files. GCC's limits.h does not include Newlib's limits.h: instead, Newlib's limits.h includes GCC's limits.h. So it seems the compiler looks through the include directories in the wrong order.

I have fixed it temporarily by an ugly hack (adding #include <syslimits.h> at the beginning of GCC's limits.h), but this is obviously not the right solution.

I guess I should change something in GCC's parameters but I don't know much about GCC's internals.

Thanks in advance for your help.

[sortie]

You probably could do something with #include_next <limit.h> - but unfortunately I know this situation exists and I'm yet to resolve it in my personal OS-specific toolchain. I'm on vacation right now, so I can't investigate further.

[bluemoon]

Google is your friend.
http://gcc.gnu.org/ml/gcc/2003-10/msg01278.html

However, looks like it is solved, but I have not verify it.

[karuon]

Google is your friend.
http://gcc.gnu.org/ml/gcc/2003-10/msg01278.html

I have already seen this thread, recompiling and reinstalling gcc after installing and compiling Newlib didn't change anything in my case. Maybe I did not specify enough configure options ? Here my what I have tried up to now:

Code: Select all

../gcc-4.8.1/configure --prefix=/usr/local/cross --target=i586-pc-myos --disable-nls --enable-languages=c

Code: Select all

../gcc-4.8.1/configure --prefix=/usr/local/cross --target=i586-pc-myos --disable-nls --enable-languages=c --with-newlib

Code: Select all

../gcc-4.8.1/configure --prefix=/usr/local/cross --target=i586-pc-myos --disable-nls --enable-languages=c --with-newlib --with-sysroot=/usr/local/cross/i586-pc-myos

[sortie]

Thanks bluemoon, that clears up some things.

Basically, you should do as always have been recommended when setting up a cross toolchain with a system root:

• Create a system root with the target system directory structure.
• Install the kernel and libc headers into the sysroot.
• Build the cross-compiler with the system root given using --with-sysroot.
• Building the libc and installing into the sysroot.
• (building the rest of the system and installing into the sysroot)
• Building the kernel and installing into the sysroot.

This translates well into your situation where newlib is the libc, so you'll have to install its headers before building the cross-compiler. My libc has special support for generating and installing headers without a working compiler, newlib ought to be able to do that too. Otherwise, as a special hack, you can simply create a dummy limits.h inside your system root before building the cross-compiler - the cross-compiler doesn't truly need real libc headers.

[karuon]

Thanks bluemoon, that clears up some things.

What do you mean ?

Basically, you should do as always have been recommended when setting up a cross toolchain with a system root:

• Create a system root with the target system directory structure.
• Install the kernel and libc headers into the sysroot.
• Build the cross-compiler with the system root given using --with-sysroot.
• Building the libc and installing into the sysroot.
• (building the rest of the system and installing into the sysroot)
• Building the kernel and installing into the sysroot.

This translates well into your situation where newlib is the libc, so you'll have to install its headers before building the cross-compiler. My libc has special support for generating and installing headers without a working compiler, newlib ought to be able to do that too. Otherwise, as a special hack, you can simply create a dummy limits.h inside your system root before building the cross-compiler - the cross-compiler doesn't truly need real libc headers.

After building Newlib, Newlib and kernel headers were in /usr/local/cross/i586-pc-myos/include. Or maybe they should be precisely in the sysroot directory, which means here /usr/local/cross/i586-pc-myos ?

[sortie]

Thanks bluemoon, that clears up some things.

What do you mean ?

I mean what I said in the rest of my post. But, I suppose I wasn't clear enough, so I'll try be more concrete.

You'll have a system root and in it there is an include directory that will be searched by your cross-compiler. I've modified my gcc to search $SYSROOT/include, but your default cross-compiler may search in $SYSROOT/usr/include and $SYSROOT/usr/local/include. Adapt your OS-specific toolchain as you see fit.

Before you build the cross-compiler, you must install all the headers of newlib into the system root, such that gcc can detect that limits.h exists in your libc and it'll back away and simply wrap itself around it using a gcc #include_next trick.

Before you build newlib, you must build the cross-compiler.

There is a cyclic dependency here - at first. The solution is that gcc only needs the headers of newlib, it doesn't need the actual library. You should install all the newlib headers into the system root, then build gcc pointed at that system root, and finally build newlib using the cross-gcc and that system root. This way will correctly let gcc know a few things about your libc before it's even built, such that <limits.h> is provided. gcc will then override your <limits.h> with its own, but gcc's <limits.h> will include yours and then declare a few gcc specific things the compiler wants to control.

[karuon]

I've modified my gcc to search $SYSROOT/include

Which config file did you modify ?
In the configuration described in OS Specific Toolchain tutorial (http://wiki.osdev.org/OS_Specific_Toolchain), does SYSROOT refer to /usr/local/cross/i586-pc-myos ?
I have also had a look at Boomstick script (https://github.com/xomboverlord/buildto ... r/build.sh), which seems to make no use of option --with-sysroot. Why ?

[sortie]

Hi karuon,

You seem very confused about what a "system root" exactly is. It is quite simply a directory on the current system that contains what usually goes into the target system. For instance, if I have an operation system called 'myos' that normally have directories like /bin, /etc/, /usr, /usr/bin, /usr/include, /usr/lib and so on - then if I cross-compile to myos from a Linux system and I store the system root at /home/sortie/myos-sysroot, then I would have the directories /home/sortie/myos-sysroot/bin, /home/sortie/myos-sysroot/etc/, /home/sortie/myos-sysroot/usr, /home/sortie/myos-sysroot/usr/bin, /home/sortie/myos-sysroot/usr/include, /home/sortie/myos-sysroot/usr/lib and so on.

When I say "install a package" into a system root, I really mean "install a package into its --prefix prefixed with the given system root". That is, to install /usr/include/limits.h into the system root, you would create the file /home/sortie/myos/include/limits.h. So no, I am not talking about dumping files into the root directory of the system root, but rather copying files into the system root plus what they normally would be called.

You can view the patch that adds support for my OS to gcc here:native_system_header_dir=/include
https://gitorious.org/sortix/gcc/commit ... 0e4f98151a

Basically I set native_system_header_dir=/include in gcc/config.gcc (see the patch). This controls the location where gcc looks for headers relative to the system root.

Don't pay too much attention to boomstick, I never used it - and I don't know whether the authors knows all these specifics. My recommendations are based on my own experiences and I'm confident they should apply well to others (well, if their OS is relatively Unix-like).

[karuon]

[A system root] is quite simply a directory on the current system that contains what usually goes into the target system. For instance, if I have an operation system called 'myos' that normally have directories like /bin, /etc/, /usr, /usr/bin, /usr/include, /usr/lib and so on - then if I cross-compile to myos from a Linux system and I store the system root at /home/sortie/myos-sysroot, then I would have the directories /home/sortie/myos-sysroot/bin, /home/sortie/myos-sysroot/etc/, /home/sortie/myos-sysroot/usr, /home/sortie/myos-sysroot/usr/bin, /home/sortie/myos-sysroot/usr/include, /home/sortie/myos-sysroot/usr/lib and so on.

I don't really understand the phrase "what usually goes into the target system". Does it mean that my sysroot (in this example /home/sortie/myos-sysroot") should contain exactly the same files as the root of my OS file system?

Taking OS Specific Toolchain tutorial as a basis, what should I change exactly to make my Toolchain work properly ? Is it enough to create a sysroot directory, copy the Newlib headers to sysroot/include, specify /include as a header directory in gcc/config.gcc, and finally configuring GCC exactly as in the tutorial just adding --with-sysroot options?

Or could you just show me your configure script options?

Thanks for your help.

[sortie]

[A system root] is quite simply a directory on the current system that contains what usually goes into the target system. For instance, if I have an operation system called 'myos' that normally have directories like /bin, /etc/, /usr, /usr/bin, /usr/include, /usr/lib and so on - then if I cross-compile to myos from a Linux system and I store the system root at /home/sortie/myos-sysroot, then I would have the directories /home/sortie/myos-sysroot/bin, /home/sortie/myos-sysroot/etc/, /home/sortie/myos-sysroot/usr, /home/sortie/myos-sysroot/usr/bin, /home/sortie/myos-sysroot/usr/include, /home/sortie/myos-sysroot/usr/lib and so on.

I don't really understand the phrase "what usually goes into the target system". Does it mean that my sysroot (in this example /home/sortie/myos-sysroot") should contain exactly the same files as the root of my OS file system?

Dude - read my posts, *again*. You ask me a question that my example answers. I even spelled it out for you.

Taking OS Specific Toolchain tutorial as a basis, what should I change exactly to make my Toolchain work properly ? Is it enough to create a sysroot directory, copy the Newlib headers to sysroot/include, specify /include as a header directory in gcc/config.gcc, and finally configuring GCC exactly as in the tutorial just adding --with-sysroot options?

Yes, that's exactly what I am suggesting. You can also don't change anything in gcc/config.gcc and use sysroot/usr/include instead as that is the default. This is up to you.

[karuon]

I did as you said and it my toolchain works now. Thanks for your patience.

[sortie]

Glad to hear it.