kernel.cpp: undefined reference to

[jpacanowski]

Hello, guys

Why do I get this warning?

kernel.cpp:19: undefined reference to 'itoa(int, char*, int)'

I've tried everything and I don't know what to do... I spent 2 days trying to fix it...
Everything seems to be OK.

https://github.com/jpacanowski/GekonOS

Help me please.

[FallenAvatar]

You don't have a C Standard Library.

- Monk

Edit: After looking at your code (since you didn't post any useful info here) I see that you have the start of a libc, looking at your build.sh, you aren't using a cross compiler, start by fixing that.

[jpacanowski]

You don't have a C Standard Library.

See my source code...
/libc/stdlib.c
there is one function, itoa(), so far.

What do you mean by cross compiler? Why do I need it?

[glauxosdever]

Hi,

You don't have a C Standard Library.

- Monk

Actually he defines the function in the libc, and then he links the kernel against it.

Maybe try to see if the spacing is correct? Maybe some zero-width spaces or non-breaking spaces have sneaked in? That's probably why is the symbol named "itoa(int, char*, int)" and not "itoa". The rest should be the parameters.


Regards,
glauxosdever

[neon]

You shouldn't be including stdlib.h like that given that it declares a function that was compiled with c name mangling rather then c++. If you are going to use c++, create a separate header for c++ symbols and wrap it inside an extern "c" block. Alternatively, use stdlib.cpp rather then stdlib.c.

I would also recommend not naming your functions off of the same functions used by the c run time library. You aren't implementing the c run time library - rather, you should be implementing a separate run time component for the kernel and kernel mode drivers. Don't give functions the same name as the c run time library counterparts when its not implemented up to the actual standard.

[jpacanowski]

Maybe try to see if the spacing is correct? Maybe some zero-width spaces or non-breaking spaces have sneaked in?

spacing? what's that? Could you tell me more about it? It's the first time I heard about that. I'm about to give up.

[glauxosdever]

Hi,

I would also recommend not naming your functions off of the same functions used by the c run time library. You aren't implementing the c run time library - rather, you should be implementing a separate run time component for the kernel and kernel mode drivers. Don't give functions the same name as the c run time library counterparts when its not implemented up to the actual standard.

He should be implementing a stripped down C library for use with the kernel. To distinguish from a full C library, the kernel version of the C library is by convention called libk (sortie uses this convention too). There is much less code duplication this way.

spacing? what's that? Could you tell me more about it? It's the first time I heard about that. I'm about to give up.

If there is a ZWSP (zero width space) somewhere, instead of a normal space, it will not be necessarily treated like a space in this case. In fact, it's not specified by the C standard as an acceptable space character and you shouldn't rely on it. Same with a NBSP (non-breaking space), which is more probable here, since "itoa(int, char*, int)" is treated as a symbol as a whole. As a last resort, you can always look it through a hex editor to determine if a strange space or whatever strange character exists there.

Hope this helps.


Regards,
glauxosdever

[jpacanowski]

Thank all of you so much. It works I compiled libc with g++ and not gcc.

[neon]

He should be implementing a stripped down C library for use with the kernel. To distinguish from a full C library, the kernel version of the C library is by convention called libk (sortie uses this convention too). There is much less code duplication this way.

Sure, we agree and I even recommended it. The part we disagree at is in the naming -- This run time component implements some run time functionality common to the C run time library, but it is, in fact, not a subset of the C run time library nor its implementation. Calling a function by the same name as the CRT when it does not in fact implement proper functionality as defined by ISO C is lying.

[glauxosdever]

Hi,

Thank all of you so much. It works I compiled libc with g++ and not gcc.

I'm glad it works. Still, I'm wondering how can a function call be interpreted as a symbol as a whole when using gcc, but be interpreted correctly when using g++. Seems strange...

Also, if you are using C++, then your itoa() function declaration and implementation is wrong. See here for the reference.


Regards,
glauxosdever

[Octocontrabass]

Still, I'm wondering how can a function call be interpreted as a symbol as a whole when using gcc, but be interpreted correctly when using g++.

The library compiled with gcc is using non-mangled names, but the kernel compiled by g++ is looking for mangled names (i.e. the library's header file doesn't specifically include extern "C"). In order to make human-readable error messages, mangled names are demangled before output. The error message refers to "itoa(int, char*, int)" because that's the demangled version of the symbol it's searching for.

The real issue here is attempting to link C and C++ code without using extern "C".

[Schol-R-LEA]

What do you mean by cross compiler? Why do I need it?

Since everyone else seems to have missed this question: a cross-compiler is a compiler running on one platform and OS, but producing output targeting a different platform and/or OS. See "Implications of writing a freestanding C project", "Why do I need a Cross Compiler?", and " GCC Cross-Compiler" for a more detailed explanation of the issues at hand.

In this case, the real issue is that GCC by default links in the current system's standard library functions when a call to a standard library function is made. While this can be suppressed entirely using the --ffreestanding and similar switches, this becomes tedious and error prone; it is better to set up an OS-Specific Toolchain separate from the development host's toolchain, instead. The details for setting one up can be found in the wiki at the pages linked above.

[Combuster]

Oh, I noticed.

Just to make a note here:

undefined reference

Violates the forum rules on Required Knowledge and smart questions. After all, this is a very basic beginner error in C. Then,

What do you mean by cross compiler? Why do I need it?

is equally bad: you haven't searched (There's a nice "Got a question? Search this first" at the top of the screen) for a GCC Cross-Compiler, you haven't read the FAQ (it's in there), you haven't read the forum rules ("REQUIRED READING"), and both queries look totally oblivious for any personal time investment. Basically you've done everything that would have given me an excuse to kick you straight out of this forum again.


Don't do that again, please.

[jpacanowski]

I know what a GCC Cross-Compiler is. I asked why do I need it, but I received the answer. Don't you see the difference between What is... and Why...?

In this case, the real issue is that GCC by default links in the current system's standard library functions when a call to a standard library function is made.

itoa() is not a standard library function.

It is better to set up an OS-Specific Toolchain separate from the development host's toolchain, instead. The details for setting one up can be found in the wiki at the pages linked above.

Ok, I will try. But isn't that enough for now?

Code: Select all

CFLAGS="-m32 -c -g -O2 -W -Wall -Wextra -Werror "\
"-ffreestanding -std=gnu99 -fno-builtin -nostdinc -Ikernel/include"

ld -g -m elf_i386 -T link.ld [...]

I mean,

-m32
-nostdinc
-m elf_i386

[mariuszp]

It is better to set up an OS-Specific Toolchain separate from the development host's toolchain, instead. The details for setting one up can be found in the wiki at the pages linked above.

Ok, I will try. But isn't that enough for now?

Code: Select all

CFLAGS="-m32 -c -g -O2 -W -Wall -Wextra -Werror "\
"-ffreestanding -std=gnu99 -fno-builtin -nostdinc -Ikernel/include"

ld -g -m elf_i386 -T link.ld [...]

I mean,

-m32
-nostdinc
-m elf_i386

No.

Using those flags is trying to work around problems which should not even exist; the real problem is that you're using a compiler targetting Linux (I suppose), instead of a compiler targetting your operating system. You don't need an OS-specific toolchain yet - you'll need that once your OS can load applications. You still, however, need a compiler that does not target Linux, but instead is suitable for compiling a kernel of another OS, which in your case (based on the options you've given) would probably be i586-elf, i686-elf or similar.