views:

210

answers:

3

I'm trying to compile the Neko VM on Mac OS X (10.5.7) using GCC 4.01 and I'm completely stuck, because it stops while compiling saying:

vm/threads.c:202: error: conflicting types for 'neko_thread_register'
vm/neko_vm.h:37: error: previous declaration of 'neko_thread_register' was here

I've tried googling this and some say it's because of lack of a "prototype" and some say it's because of a header include being done several times, and I can't really find any of those.

The affected line in threads.c:202 looks like this:

EXTERN bool neko_thread_register( bool t ) {

And the affected line in neko_vm.h:37 looks like this:

EXTERN bool neko_thread_register( bool t );

I can't see any difference in them, besides one of them being the implementation of the other.

The compiler command I'm using is:

cc -Wall -O3 -v -fPIC -fomit-frame-pointer -I vm -D_GNU_SOURCE -arch i386 -L/usr/local/lib -L/opt/local/lib -I/opt/local/include  -o vm/threads.o -c vm/threads.c

I'd appreciate some ideas on what i might be able to do here, I don't really know where to go from here.

A mirror of the code for Neko which I'm trying to compile can be found here.

Thanks!

+1  A: 

First, make sure you compile this as C, not C++.

Second, without seeing the code, it's pretty much impossible to say what the problem is. But reading the error messages is often helpful (even before you google them):

Apparently neko_thread_register is declared twice, once in threads.c:202 and once in neko_vm.h:37, and the two declarations have different (conflicting) types. So look at the two declarations. If you can't see a problem with them, show us some code.

At the very least, seeing those two lines of code would be necessary. Most likely, the types are typedefs or macros or something similar, and then we'd need to see where they are defined as well.

Without seeing the code, all we can do is repeat the compiler error. "neko_thread_register has two conflicting definitions, at the lines specified."

jalf
A mirror of the related files can be found here:http://github.com/slaskis/neko/tree/2c6eabb567fd6297de5281a4347a98e30ff41e94/vm
Robert Sköld
Yes, but you're the one who need the question answered. I think it's only fair if you do the work of finding the relevant code. I don't want to go browsing through the entire NekoVM codebase for you, but I don't mind taking a look at any relevant code snippets you post here. :)Always make it easy for people to answer your questions. ;)
jalf
Off course, well i thought it would be easier for you reading the files there on github than fetching the whole repository from cvs. And i also pointed to the directory where those two files in the error was listed (threads.c and neko_vm.h) and i doubt the lines of the error itself will help. I have been looking, still am, but i haven't found anything so i thought i'd ask someone who might be more experienced in debugging compiler errors as this is pretty much the first time i've had to myself. But i appreciate your efforts to make me describe the problem better :)
Robert Sköld
Well, can you post the contents of the two lines it points to at least? That'd be a good starting point. The compiler errors are pretty useless without the code. :)
jalf
Absolutely, updated the question with lines and appropriate links to the lines in the codebase.
Robert Sköld
A: 

Did you uncomment this line:

# For OSX
#
# MACOSX = 1   <-- this one

In the makefile?

e.James
I didn't, but running "make universal" sets MACOSX=1 and OSX_UNIVERSAL=1 which then gives the command in the question.
Robert Sköld
Ah, OK. It was worth a shot :)
e.James
Appreciate the attempt :)
Robert Sköld
+1  A: 

Have you tried compiling that file alone and outputting the preprocessed version? It could be that the scope or linkage macros are being modified somewhere in between the header file and the implementation file-- the same could be true of the 'bool' type, which is usually a macro defined by a system header.

According to the GCC 4.2 docs here, you should need to add the -E flag to the compilation line above, and you ought to change -o vm/threads.o to -o vm/threads.i so a file with the correct extension is created (.i means 'preprocessed file', essentially).

Jim Dovey
Cool, i didn't know this could be done, but the output is terrible to read :) (result: http://gist.github.com/113449) But it does seem like the bool typedef gets converted to a _Bool (from /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/stdbool.h) which makes sense since the issue is only on osx. Thank you, atleast now I (might) know where the issue lies :)
Robert Sköld
Indeed it was the issue, workaround was to add #include <dlfcn.h> before including the vm.h (which sets the bool typedef). Now it's other obstacles off course, but atleast this question has been answered :) Thanks again!
Robert Sköld
Excellent. Another option might be to ensure that <stdbool.h> gets included everywhere early on, perhaps in something like config.h which is probably included before most other things.
Jim Dovey