Talk:OS Specific Toolchain

From OSDev Wiki
Jump to navigation Jump to search

Proposal: I think we should simplify this page and remove the binutils part about the emulparams. It is not really necessary to create custom emulparams since those existing for the target should be sufficient (elf_i386/elf_x86_64 in this case). This makes the whole setup simpler since automake'ing isn't required anymore either. What do you think? --Max 14:00, 11 October 2022 (CDT)



Excellent work! As for how to continue with this... I was originally intending what is the GCC Cross-Compiler article today to become a multi-part tutorial, starting with the cross-compiler setup and ending with a self-supporting OS. You can see the stubs for the later steps in the article. Of course I would prefer that tutorial to include PDCLib instead of newlib, but newlib is available today. Maybe it's time to expand the cross-compiler tut. into the multi-part thing it was originally meant to be? Opinions? Solar 06:21, 13 September 2007 (CDT)


I'm not familiar enough with the inner workings of gcc and binutils to say something meaningful about it, but I wonder to what extent a stage 2/3 cross-compiler would be buildable with a plain unmodified i586-elf target. If it is, this tutorial is just a sidestep for the geeks who see the uses of a specifically named toolchain (or just want gcc to be named after them) and the cross-compiler tutorial is mostly independent.
On the other hand, the cross-compiler tutorial is for most people to just get a stage 1 compiler which is suitable for kernel development. It could be wise to use the crosscompiler page for just that, and build a stage 2/3 and stage 4 crosscompiler in separate articles (something like, this article and Porting GCC).
I posted a PM to the author in the meantime in which I said that this article is very well suited for inclusion in the main namespace. Independent of what we are to do with it, I don't think we should withhold other uses from finding and using this article. At worst somebody discover errors, which isn't even too bad since we can fix that later.
@Solar: I tried once building a stage 2 gcc with PDCLib but it failed with conflicting types for size_t so I guess newlib is for now the way to go.
- Combuster 10:46, 13 September 2007 (CDT)


Okay, its moved. GCC and binutils are quite interlinked so should remain in the same section. I don't, however, see any problem with splitting the newlib bit into a separate section (although then the overlap with Porting Newlib is quite apparent), so we could just have links at the bottom of the GCC/binutils bit to the newlib page and also to a (future) PDCLib page. Unfortunately, I don't have much experience with PDCLib. Originally, I tried with glibc (glutton for punishment) but eventually gave up trying to understand their definition of 'unix' and 'posix' (they implement some aspects of the Single Unix Specification, and you implement the rest. Unfortunately, they don't explain anywhere what you are supposed to implement, and adding each function tended to require a complete rebuild, including reconfiguring every directory). I chose newlib late one night because pcmattman had already demonstrated proof-of-principle.
I'm all for expanding the cross compiler tutorial, but have concerns that we might make it too complex beyond the level of instructing new visitors on the methods for building a cross compiler. Basically, I don't want to fill up the forum with lots of simple questions from people not following the instructions precisely. It should be made extremely clear that this article is not intended for beginners.
As I've now moved this article to the main namespace, I'll remove the 'Creating a new binutils target' which was my forerunner to this article and is really just a less-well written and designed version of the first section.
Many thanks for your kind comments. John 12:39, 13 September 2007 (CDT)
Also, I'm adding this to the tutorials category, but think it might be wise to maybe create a subcategory on tutorials for creating user-space tools or something, because otherwise it might become one of the first ports of call for people looking for an 'OS development tutorial'. I've made a comment to that effect on the Tutorials talk page. John 12:44, 13 September 2007 (CDT)


If needs be, you can overwrite my version of the Porting Newlib article with your description, which is more in-depth than mine. Specifically, it covers adding a new system as your newlib target, which I couldn't find out how to do properly. I'll be referring to this tutorial later when I get around to porting the toolchain to my OS - it's really well done.
- Pcmattman 23:30, 14 September 2007 (CDT)


I've spent a lot of time reading through the GCC source and various docs and think I have a very good understanding of how to 'properly' specify target specific behavior when adding a new OS target to both binutils and GCC. For now, I'm writing up some documentation on this offline, and will eventually post it under my user namespace. I'll post here (and on the forum) when I have that done. If this really is the proper place for that kind of document (there doesn't seem to be a consensus here), I'll happily post the 'finished' doc here, but right now I think that Porting GCC is a more likely place for it.
--Quok 06:08, 26 August 2008 (UTC)


I am working on some modifications to this guide that will allow initializers (_init and _fini) to work. Also I will be working on some stuff that will allow these initializers to work in the kernel. --uglyoldbob 13 Oct 2008

Grid of Successful Configurations

As suggested on the forum, I am submitting a successful configuration for following this tutorial. Perhaps once there are enough of these, we can sort out how to format the information. For my part: 

cygwin-based:
i586-pc-caracal - based strictly on the tutorial using binutils 2.18 and GCC (with g++) 4.2.2.
x86_64-pc-caracal - same version of GCC and binutils using x86_64 as a template.
                  - Extra emulation target added: i386 elf and coff.

Thanks for the excellent tutorial and help on the forum!

The following quokos targets now exist as patches in the QuokOS svn repo: 

 i[3-7]86-pc-quokos - Loosely based on this tutorial with other additions.
   emulations: elf32_i386, efi_app_ia32
   64-bit emulations: elf64_x86_64
 x86_64-pc-quokos - Based on the above target, with the same additions plus x86_64 specific bits.
   emulations: elf64_x86_64, efi_app_x86_64
   32-bit emulations: elf32_i386, efi_app_ia32

The quokos target patchset was initially based on GCC 4.2.4 and Binutils 2.18, but has been applied to different versions and configurations of GCC from 4.0+ and Binutils 2.16, 2.17, and 2.18. For the GCC 4.2.4 / Binutils 2.18 combination specifically, the build succeeds on openSUSE 10.3, 11.0, Debian Etch, Cygwin, OSX 10.5, and OpenBSD 4.3. If anyone wants the details of what else I changed, or wants the patches themselves for some reason, just PM me. --Quok 06:08, 26 August 2008 (UTC)

Implementation notes

This tutorial has worked for me with GCC 4.5.0 and Newlib 1.18.0. I came across two errors when compiling Newlib. The first was exactly the same as in [forum:17777 this thread], but this was because there were compilation errors in my system call stubs; my best guess is that Make would try to compile them, fail, abort the entire compile process, then continue onwards assuming that it had succeeded. The second error was when I ran 'make install'. /usr/bin/install couldn't stat newlib/libc/sys/myos/netinet/*.h. For lack of a better way to disable networking (I presume) functionality, I simply created the folder structure as indicated and created an empty file, Net.h. This could probably be done better, but for a quick and dirty hack it seems to work. --Computafreak 09:41, 30 August 2010 (UTC)

I tried this with bleeding edge binutils-2.22, gcc-4.6.2 and newlib-1.20.0. I had a few issues, the most important one is that gettimeofday() syscall is wrong. Removing the row made it compile but should probably be changed. Also I had to add --without-headers and --with-newlib when running configure for gcc --Jezze 22:27, 6 January 2012 (CST)

Binutils not building GNU gold linker

Even when adding --enable-gold --enable-lto --enable-plugins to the Binutils configure script, the gold linker is not being built. It is built for the target i686-pc-elf, but not i686-pc-myos. I'm not sure whether you have to enable gold for the myos target and where. It seems that $SRC/gold/configure.tgt does not require any changes. I just wanted to mention this. Using binutils-2.21. --Walling 21:57, 7 April 2011 (UTC)

I found the answer. You have to enable the gold linker for your target. It is easily done in the main configure.ac file. Look for Handle --enable-gold, --enable-ld and find the line # Check for ELF target. Now add your target in the case "${target}". I added *-*-myos* after *-*-irix6*, because there was some space left. Then run autoconf in the same directory as the configure.ac file. It will generate a new configure script. Now you're able to configure (in a build directory) and make. --Walling 13:24, 8 April 2011 (UTC)

Newlib sys/myos Makefile.am problem

It appears that in newer versions of Newlib (I'm trying to use 2.1.0), if you create the Makefile.am for your system as suggested below: 

 if MAY_SUPPLY_SYSCALLS
   extra_objs = syscalls.o
 else
   extra_objs = 
 endif

than, the extra_objs assignment is added after the rest of the assignments in the actual Makefile. So, for example, in the Makefile (after configuration) it would look something like this: 

 lib_a_SOURCES =
 lib_a_LIBADD = $(extra_objs)
 EXTRA_lib_a_SOURCES = syscalls.c crt0.S
 lib_a_DEPENDENCIES = $(extra_objs)
 lib_a_CCASFLAGS = $(AM_CCASFLAGS)
 lib_a_CFLAGS = $(AM_CFLAGS)
 ... # A lot of other stuff, approximately 300 lines
   extra_objs = syscalls.o
 # extra_objs =

This makes lib_a_LIBADD empty, and therefore never compiles your syscalls. The solution is to remove the conditional and make it simply: 

 extra_objs = syscalls.o

It was a rather annoying bug to track down. I'm not sure of the ramifications of ignoring the MAY_SUPPLY_SYSCALLS macro, but I am currently ignoring it and newlib is compiling happily. I assume this is happening because the configure script/automake makes two passes. First evaluating assignments and adding them all to the script, then second evaluating all conditionals and adding remaining assignments to the script. So on pass one, all the variables are dumped into the Makefile, then the if block is tested and extra_objs is placed inside the Makefile after all the other assignments (which in this case is a problem). --Caleb1994 17:11, 4 September 2014 (CDT)

Retrieved from "https://wiki.osdev.org/index.php?title=Talk:OS_Specific_Toolchain&oldid=27466"