OSDev.org

Hello.

First, I am new to kernel development. I must say I find it very interesting and fun. But at the same time so frustrating because of these problems.

I know, there were a lot of people with this problem. I know I should build a cross-compiler. I want to avoid that for now.

First, I thought it was my error. But its not. I followed Brans Kernel tutorial step by step exactly. And I get the following problem:

I passed -nostdinc -fno-builtin but still GCC thinks its cool that it puts __main and __alloca in my object files. What can I do? I have GCC 3.4.5 (MinGW special). Why does it put these symbols in there if I explicitly say that it should not?

Thank you.

I've had the same problem. It gave me a few headaches. I don't remember the exact solution (it was a few months ago). But what I remember is that it was something about the name of the main function. I guess you have source file with "int main(some parameters)" declaration. Could you please try changing that to this:

int _main(some parameters)

Maybe is not the most elegant solution, but I worked for me

GCC Cross-Compiler and search first next time

IIRC, __alloca is used to allocate a certain amount of space on the stack. It takes a size_t parameter and returns a void*, although this is not guaranteed and this could even vary between GCC versions.

As you suspect and as you will get fed up of hearing - build a cross compiler rather than trying to implement this yourself

Cheers,
Adam

__alloca() is a stack-handling function from the Windows runtime. The fact that your compiler is trying to reference that function shows that you are trying to generate a Windows executable. The solution is to either find the correct command line options to turn this off, or (better) to use a compiler that doesn't assume Windows as default target - hence the "use a cross-compiler" sentiment.

It might seem like rubbish to use a cross-compiler, at first I didn't see the sense in it either. But then I tried it and... well it just works.

I searched and I found. But not a solution. Build a cross-compiler? Sure, I would be happy to. I also tried it. Its not as easy as it looks in the Wiki. I guess I'll try again today.

But I want to be clear. What kind of exes will the cross-compiler build? I guess if I build GCC on Windows, I will get ELF executables, right?

Ah, guess its back to the cross-compiler.

Hi,

miha wrote:But I want to be clear. What kind of exes will the cross-compiler build?

If you follow the tutorial exactly, your target will be i586-pc-elf (ELF32 format). Once you are happy with doing this, it is perfectly possible to adjust the target to, for example, x86_64-pc-elf.

Cheers,
Adam

Sorry for not opening a new thread for this, but it just seems that its not worth it. I compiled binutils successfully. But now, when I try to compile GCC 4.0.0 (I tried already with GCC 3.4.5) with the configure line:
Everything goes fine except that it doesn't find c++. So only C is supported. Then I try to make gcc-all everything:
What could be causing this?

Firstly, don't use a crusty old version. Use GCC 4.2 at the latest.

Secondly, you need to download the 'C++' tarball as well as the core package in order to enable C++.

OK, I got pretty far this time. But somewhere in the late stages of the compilation, this happened:



Hmm.. The paths don't seem right. And I don't know what the -isystem parameter does. :/

mingw is very flaky, you should install gcc through cygwin and build a cross compiler (from normal gcc sources) with the gcc from cygwin. I promise you that will work if you follow the instructions.

Also, make sure you remove anything unneeded from the path variable: (keep only the cygwin directories and windows directories listed by the first command)