OSDev.org

Over this weekend, angered by my inability to reproduce a working set of buildtools for XOmB, I produced a simple script to automate the process. I generalized it for any OS target, but it should only work for intended x86-64 elf targets.

Simply give it the name of your OS and fill out the newlib stubs with your system call interfaces and employ the script. It will pull the sources for binutils, gcc, and newlib; patch them; and build them. It will produce a working C and C++ to build and port applications to your OS. You can edit the version numbers of the sources in the script, however it is set to the latest releases and is known to work with these.

As for drawbacks... I would REALLY like a Fortran target for benchmarking, and cannot get the bugger to build. Any help on this would be appreciated if anybody would like to extend the capability of the script or tell me how. (Add fortran as a language in the script, and watch it fail )

The source is here with a simple README:
http://github.com/xomboverlord/buildtools

It is, of course, licensed under the WTFPL, so fork away! (Also, on behalf of the XOmB team, happy zombie Jesus day)

Do you know about http://www.kegel.com/crosstool/?

Solar wrote:Do you know about http://www.kegel.com/crosstool/?

Yes. Quite impressive, of course. But he drops newlib support and the last update was in 2006. And his is GPL'd... c'mon... WTFPL... more permissive AND swearing? Can't beat it!

The point of our script is to incorporate a newlib system implementation and build compilers that use it with a new target. So this will basically automate the process illustrated in the wiki under Porting Newlib, OS Specific Toolchain (which is a bit out of date), Building GCC, Building GMP, and Building MPFR in an easy to use script. So as long as these wiki articles are useful, so will the script. You get crt0.c and syscalls.c, you fill them out, and you run the script, and there you go, a full C environment.

The way we do it is we have a branch for our specific OS in this repo with our crt0 and syscall bridge for newlib. This is the way it should be. A branch for each target. Could you imagine if GCC had branches for each target so you only pulled the source you need? So, this is also an elegant way to separate your kernel and userspace from the mess GCC makes you deal with.

The main problem with the fortran target is that it... well... pukes on newlib. So his crosstool still isn't of any use because of its outdatedness and its ignorance of newlib. It is mostly configuration issues that prevent libgfortran from compiling... so I guess I could ignore them and see how far I get. But it induces anger. Why doesn't it just work?

The latest release of this script, Boomstick, is now documented on the wiki. We have used it sucessfully to build C apps for XOmB capable of using malloc and stdio functions.

The gfortran compiler builds a functional executable. However we are hitting a weird issue, probably resulting from our customized crt0, that leads to it printing an error message to the console, rather than 'hello world'.