Visual Studio linker problem

[Adrenalin2]

I have been trying to compile the seti@home client for three days now without success. I am using Visual Studio 2005 to compile it, but after excluding the seti_boinc_private.rc file I have a linker error at the end of the process:
Error   1   error LNK2001: unresolved external symbol _boinc_app_mouse_button   libboincapi.lib   
Error   2   error LNK2001: unresolved external symbol _boinc_app_mouse_move           libboincapi.lib   
Error   3   fatal error LNK1120: 2 unresolved externals   c:\.....\setiathome_5.17_quantum.exe

These symbols are defined as external functions inside the libboincapi.c. Where are they usually implemented?
Unfortunately the .manifest file is only built by the debug configuration and not by the release config. Is this file necessary for the build process? Can someone help me resolving this errors?

[Simon]

Adrenalin,

the Manifest problem can be easily resolved by creating an empty file called xyz.Manifest (you choose the name, but the extension has to be .Manifest), then enter the name of that file in seti_boinc_private.rc.

This is a VS 2005 problem only, and it's annoying but pretty easy to fix.

About the other, that's an error in S@H code I sent to Eric Korpela a while ago, he said it should be fixed. Eric, did that ever make it into the S@H tree?

Inside sah_gfx.cpp, find boinc_app_mouse_move and boinc_app_mouse_button. They will have a definition like the following:

void boinc_app_mouse_move( int x, int y, int left, int middle, int right )
[...]
void boinc_app_mouse_button( int x, int y, int which, int is_down )

void boinc_app_mouse_move( int x, int y, bool left, bool middle, bool right )
[...]
void boinc_app_mouse_button( int x, int y, int which, bool is_down )

I've highlighted the incorrect parts in red and the corrected parts in green. S@H should now compile. Took me forever initially to spot that...

HTH,
Good luck compiling!
Simon.

[Adrenalin2]

Thank you, Simon. It took me the whole day to find that error. 
Now everything compiles fine. Maybe you will see a new client working on a system which is one magnitude faster than current hardware within the next weeks. Seems to be quite complicated and needs huge modifications, but I will post here when/if its done. 

[Simon]

Great
Good luck and let us know how it goes.

Regards,
Simon.

[Urs Echternacht]

Adrenalin,

the Manifest problem can be easily resolved by creating an empty file called xyz.Manifest (you choose the name, but the extension has to be .Manifest), then enter the name of that file in seti_boinc_private.rc.

This is a VS 2005 problem only, and it's annoying but pretty easy to fix.

O.K.

About the other, that's an error in S@H code I sent to Eric Korpela a while ago, he said it should be fixed. Eric, did that ever make it into the S@H tree?

Inside sah_gfx.cpp, find boinc_app_mouse_move and boinc_app_mouse_button. They will have a definition like the following:

void boinc_app_mouse_move( int x, int y, int left, int middle, int right )
[...]
void boinc_app_mouse_button( int x, int y, int which, int is_down )

void boinc_app_mouse_move( int x, int y, bool left, bool middle, bool right )
[...]
void boinc_app_mouse_button( int x, int y, int which, bool is_down )

I've highlighted the incorrect parts in red and the corrected parts in green. S@H should now compile. Took me forever initially to spot that...

HTH,
Good luck compiling!
Simon.

Simon,
i don't believe this should be a problem within C/C++ because the type "bool" is usually mapped onto the type "int" (synonymous use). Till today the seti@home code (5.17 at CVS) has not been changed at that functions. When compiling seti@home applications successfully a few weeks ago, i did not see these errors. So i have to ask me now, what did i do different to compile successful?

Urs

[Simon]

Pretty easy to answer, Urs,

depending on what BOINC version you're using to link, you either get undefined symbol errors when linking or you do not.

The real problem is that the definitions differ in the boinc and seti_boinc source trees. The fix I proposed works with the source tree that is online on this site.

'Nuff said
Simon.