Trying to compile kernel... /bin/sh: 1: Syntax error: "(" un

[BMW]

I switched to ubuntu for OSDev, and am using Code::Blocks IDE.

When I try to compile my kernel, I get this error:

Code: Select all

/bin/sh: 1: Syntax error: "(" unexpected

There are no extra brackets in my code.

[FallenAvatar]

What about in your makefile/linker script?

- Monk

[BMW]

there shouldn't be a mistake there..... wtf that comes with code blocks doesn't it?

[FallenAvatar]

http://wiki.osdev.org/Required_Knowledge

Specifically, point 6 and 7.

- Monk

[linguofreak]

wtf that comes with code blocks doesn't it?

I don't understand this question. You may have left a word out between "doesn't" and "it".

[iansjack]

Obviously this is a question that is impossible to answer without seeing the source code and any associated headers (not that I'm asking you to post it!).

This sort of error commonly arises because of a problem with a missing or incorrect header file. It might even be something as simple as a header file that is incorrectly terminated (no linefeed character in the final line). If you have any includes before the offending line you may want to check them.

[Combuster]

I'll add the "learn to read" comment. The process throwing the error is the shell, not make or any compiler.

On that note, I've seen enough from you BMW - you can''t diagnose problems even if they're hitting you in the face, you can't ask proper questions, you are unable to provide appropriate facts in your questions, and on regular occasion, you're even posting blatantly wrong information. Your entire thought process is based on guesswork and trial and error, rather than knowing what you're doing.

On pretty much all grounds, you are a programming newbie. And right now you're also are a noob for trying to achieve something way above his capabilities.

This hobby is going nowhere right now. I suggest you go through several other more simple projects, take formal schooling if available - preferably on theoretical computer science, learn to be self-sufficient, and only ask people who expect beginner questions. In two years time, you might have learned enough to get to the point where you can deal with a project of this complexity without people doing work for you, but right now is not the time for it.

Good luck, and may the force be with you.

[BMW]

I'll add the "learn to read" comment. The process throwing the error is the shell, not make or any compiler.

On that note, I've seen enough from you BMW - you can''t diagnose problems even if they're hitting you in the face, you can't ask proper questions, you are unable to provide appropriate facts in your questions, and on regular occasion, you're even posting blatantly wrong information. Your entire thought process is based on guesswork and trial and error, rather than knowing what you're doing.

On pretty much all grounds, you are a programming newbie. And right now you're also are a noob for trying to achieve something way above his capabilities.

This hobby is going nowhere right now. I suggest you go through several other more simple projects, take formal schooling if available - preferably on theoretical computer science, learn to be self-sufficient, and only ask people who expect beginner questions. In two years time, you might have learned enough to get to the point where you can deal with a project of this complexity without people doing work for you, but right now is not the time for it.

Good luck, and may the force be with you.

thanks

[BMW]

Ok.
This is my source code:

kernel_entry.cpp

Code: Select all

#include "Print.h"

void kernel_main()
{
	PrintString32("Test");

	return;
}

Print.h

Code: Select all

void PrintChar32(char c);
void PrintString32(char* s);

Print.cpp

Code: Select all

#include "Print.h"

#define VIDMEM 0x000B8000
#define SCREEN_COLS 80
#define SCREEN_ROWS 25

unsigned int _CurX = 0, _CurY = 0;
unsigned char Colour = 0x07;

void PrintChar32(char c)
{
	unsigned char* p = (unsigned char*)VIDMEM;
	p += _CurY * SCREEN_COLS * 2;
	p += _CurX * 2;
	p[0] = c;
	p[1] = Colour;
	if(++_CurX == SCREEN_COLS)
	{
		_CurX = 0;
		if(++_CurY == SCREEN_ROWS)
		{
			//TODO: Make it scroll instead of overwriting
			_CurY = 0;
		}
	}
}

void PrintString32(char* s)
{
	unsigned int count = 0;
	while(1)
	{
		if(s[count] == '\0')
		{
			break;
		}
		PrintChar32(s[count]);
		count++;
	}
}

And this is the build log:

Code: Select all

-------------- Build: Release in Kernel ---------------

Linking native: bin/Release/Kernel
/bin/sh: 1: Syntax error: "(" unexpected
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings

These are my compiler options

Code: Select all

-fno-builtin
-fno-exceptions
-fno-rtti
-fno-stack-protector
-nodefaultlibs
-nostartfiles
-nostdlib

And linker options

Code: Select all

--entry=kernel_main()

I do not see any reason for the error to occur. It's probably staring me in the face sorry guys, but this is really annoying.

[sortie]

Although it's hardly relevant, I am curious why you use a -32 suffix on your print routines? I don't see anything 32-related going on.

Please realize that all these IDE options are useless information - because they tell things from your point of view - not from the machine point of view!

When you say

Code: Select all

-fno-builtin -fno-exceptions -fno-rtti -fno-stack-protector -nodefaultlibs -nostartfiles -nostdlib

and

Code: Select all

--entry=kernel_main()

does that mean that the commands that are actually executed would be:

Code: Select all

g++ -c Print.cpp -o Print.o  -fno-builtin -fno-exceptions -fno-rtti -fno-stack-protector -nodefaultlibs -nostartfiles -nostdlib
g++ -c kernel_entry.cpp -o kernel_entry.o -fno-builtin -fno-exceptions -fno-rtti -fno-stack-protector -nodefaultlibs -nostartfiles -nostdlib
ld --entry=kernel_main() Print.o kernel_entry.o -o kernel.bin

or? I don't know. In fact, I bet the above commands wouldn't even work!

Also your kernel_main is not the entry point, you'll need an assembly stub involved software. In addition, -fno-builtin should not be passed to the command line, because disabling builtins is a bad thing.


Here's my truthful recommendation: Stop using an IDE. Immediately. Use the command line instead. Make things work there. You quite appear to have no idea how the IDE actually executes commands, which is very essential to know for operating system developers.

[dozniak]

Code: Select all

--entry=kernel_main()

Looks like your error exactly.

[BMW]

Although it's hardly relevant, I am curious why you use a -32 suffix on your print routines? I don't see anything 32-related going on.

Please realize that all these IDE options are useless information - because they tell things from your point of view - not from the machine point of view!

When you say

Code: Select all

-fno-builtin -fno-exceptions -fno-rtti -fno-stack-protector -nodefaultlibs -nostartfiles -nostdlib

and

Code: Select all

--entry=kernel_main()

does that mean that the commands that are actually executed would be:

Code: Select all

g++ -c Print.cpp -o Print.o  -fno-builtin -fno-exceptions -fno-rtti -fno-stack-protector -nodefaultlibs -nostartfiles -nostdlib
g++ -c kernel_entry.cpp -o kernel_entry.o -fno-builtin -fno-exceptions -fno-rtti -fno-stack-protector -nodefaultlibs -nostartfiles -nostdlib
ld --entry=kernel_main() Print.o kernel_entry.o -o kernel.bin

or? I don't know. In fact, I bet the above commands wouldn't even work!

Also your kernel_main is not the entry point, you'll need an assembly stub involved software. In addition, -fno-builtin should not be passed to the command line, because disabling builtins is a bad thing.


Here's my truthful recommendation: Stop using an IDE. Immediately. Use the command line instead. Make things work there. You quite appear to have no idea how the IDE actually executes commands, which is very essential to know for operating system developers.

Well I got the -fno-builtin from the barebones tutorial.... soooo if it's not good then maybe someone should edit that tutorial. Ok I guess I could ditch the IDE.

[AJ]

It's not the IDE that's the problem - it's your linker command line. Think about how the shell works.

Locked as this is going nowhere.

Cheers,
Adam