Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have been following the guide on the wiki about creating a custom tool chain specifically for my OS. My kernel compiles fine with the new tool chain but when I go to compile a test program, ld complains that it can't find "crtbegin.o". I know the reason for this, it is because my kernel uses a custom linker script that doesn't drag in start files and the like. I also understand that "crtbegin.o" (and probably "crtend.o") come from gcc. My question is, how can I get gcc to generate these files during the build process? Even if they are just asm stubs that do nothing?
Also, if I pass "-nostartfiles" (or something like that) to my custom gcc to build the program it stops complaining about the "crt*.o" files (as expected) but then complains about not being able to find "libgcc".
I have checked the installation directories and neither libgcc or any of the start files (except for crt0 form newlib) are there. It seems that something is missing from my gcc build, but I can't figure out what.
I've tried your suggestion and it now complains about not having floating/fixed point support. It seems logical that I would have to add it myself (floating point is rather hardware dependent) but I have no idea where to add it. Google hasn't been any help here.
in my case floating point stuff works out of the box.
I do however link with ld directly rather than via gcc
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
I have been following the guide on the wiki about creating a custom tool chain specifically for my OS. My kernel compiles fine with the new tool chain but when I go to compile a test program, ld complains that it can't find "crtbegin.o". I know the reason for this, it is because my kernel uses a custom linker script that doesn't drag in start files and the like. I also understand that "crtbegin.o" (and probably "crtend.o") come from gcc. My question is, how can I get gcc to generate these files during the build process? Even if they are just asm stubs that do nothing?
Also, if I pass "-nostartfiles" (or something like that) to my custom gcc to build the program it stops complaining about the "crt*.o" files (as expected) but then complains about not being able to find "libgcc".
I have checked the installation directories and neither libgcc or any of the start files (except for crt0 form newlib) are there. It seems that something is missing from my gcc build, but I can't figure out what.
Just touch them. They don't need to contain anything, just exist.
checking whether decimal floating point is supported... no
checking whether fixed-point is supported... no
*** Configuration i586-pc-fluidium not supported
make[1]: *** [configure-target-libgcc] Error 1
Thanks everyone for the help. I've solved these problems by a) targeting i586-elf instead of a custom target which fixes the floating point issue and b) compiling all of gcc ("make all" instead of "make all-gcc") which builds a libgcc (like JamesM pointed out) and fixes the problem with the start files.
Stevo14 wrote:Thanks everyone for the help. I've solved these problems by a) targeting i586-elf instead of a custom target which fixes the floating point issue and b) compiling all of gcc ("make all" instead of "make all-gcc") which builds a libgcc (like JamesM pointed out) and fixes the problem with the start files.
Hi,
I just discovered something that might help you even more (in the process of doing the same thing): to get libgcc to compile on your custom target, edit libgcc/config.host to include your OS. To match the style of the toolchain tutorial on the wiki:
And then your make, instead of just all-gcc and install-gcc, should also have all-target-libgcc and install-target-libgcc. This will get you libgcc.a, crtbegin.o, crtend.o, etc.