Talk:OS Specific Toolchain: Difference between revisions
Content deleted Content added
Added Successful Configuration section. |
No edit summary |
||
| (13 intermediate revisions by 7 users not shown) | |||
Line 1:
'''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? --[[User:Max|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?
Line 13 ⟶ 19:
:: 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 [[Porting Newlib|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
:: Many thanks for your kind comments. [[User:Jnc100|John]] 12:39, 13 September 2007 (CDT)
Line 22 ⟶ 28:
::: - [[User:Pcmattman|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.
: --[[User:Quok|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.
--[[User:uglyoldbob|uglyoldbob]] 13 Oct 2008
== Grid of Successful Configurations ==
Line 29 ⟶ 43:
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. --[[User:Quok|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. --[[User:Computafreak|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 --[[User:Jezze|Jezze]] 22:27, 6 January 2012 (CST)
== Binutils not building GNU gold linker ==
Even when adding <tt>--enable-gold --enable-lto --enable-plugins</tt> to the Binutils configure script, the gold linker is not being built. It is built for the target <tt>i686-pc-elf</tt>, but not <tt>i686-pc-myos</tt>. I'm not sure whether you have to enable gold for the ''myos'' target and where. It seems that <tt>$SRC/gold/configure.tgt</tt> does not require any changes. I just wanted to mention this. Using binutils-2.21. --[[User:Walling|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 <tt>Handle --enable-gold, --enable-ld</tt> and find the line <tt># Check for ELF target.</tt> Now add your target in the <tt>case "${target}"</tt>. I added <tt>*-*-myos*</tt> after <tt>*-*-irix6*</tt>, because there was some space left. Then run <tt>autoconf</tt> 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. --[[User:Walling|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). --[[User:Caleb1994|Caleb1994]] 17:11, 4 September 2014 (CDT)
| |||