ACE - linkage problems

[yarono]

I'm working on MS-VS 8.

I compiled the .lib and .dll successfuly in dbg mode.

when I try to compile my program, some symbols the linker finds while others it doesn't. For example, those associated with communcation are linked, but assert is not found nor does it find SharedObject::init/info.

A simple code that does not compile in VS8 DOES compile in VS6!

Since, it would take ages to port my application to VS6, I want to successfuly compile it under VS8.
I'm really stuck. Does anyone have any solution? are there known problems with compiling ACE in VS8?

Thanks in advance,
Yaron

[weaknessforcats]

A simple code that does not compile in VS8 DOES compile in VS6!

I'm not surporised. VS6 never did work. There are at least six service packs plus many other bugs were just fixed in VC7 and VC8.

What code does not compile in VS8??

[yarono]

I'll upload the code later on.

For now I'll detail the linker erroos:
In the Reactor example the linker issues an error for the functions:
ace_assert and ACE_INET_Addr::addr_to_string.
And in the Sockets example the linker issues an error for the functions:
ACE_Shared_Object::init and ACE_Shared_Object::info.

[weaknessforcats]

Linker issues mean the code compiled and you are missing libraries for the linker.

Have you added the ACE libraries to the linker property for additional dependencies in your project??

You will also need to add the path to those libraries under Tools/Options/Project and Solutions/VC++ Directories.

[yarono]

Linker issues mean the code compiled and you are missing libraries for the linker.

Have you added the ACE libraries to the linker property for additional dependencies in your project??

You will also need to add the path to those libraries under Tools/Options/Project and Solutions/VC++ Directories.

Yes I have added the *.lib and the pathes are fine. It seems like that some of the symboles it finds in the ACEd.lib, but some it doesn't.
The error I get is:
error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual int __thiscall ACE_INET_Addr::addr_to_string(unsigned short * const,unsigned int,int)const " (__imp.....

[yarono]

more errors I get (from another piece of code):

error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl ACE_Log_Msg::log(enum ACE_Log_Priority,unsigned short const *,...)"

error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl __ace_assert(char const *,int,unsigned short const *)"

[weaknessforcats]

dllimport means you are using a dll. I(t looks like you are doing a static linke using a dll.

Do you in fact have that dll?

[yarono]

dllimport means you are using a dll. I(t looks like you are doing a static linke using a dll.

Do you in fact have that dll?

Yes we do have ACEd.dll, but the linker doesn't suppose to know about it...

[weaknessforcats]

OK. But if you are using load-time linking, then the linker uses the .lib that corresponds to the dll. This .lib has enough info so you can call your functions in the dll. At load time, the loader looks for the dll, loads it, and resolves rthe addresses of the function calls.

That means all of the dll functions must be extern "C" in the function prototypes. I assume this is true?

If the dll was compiled by a C++ compiler, then the function names are mangled unless the dll builder also marked the files extern "C". Do you kow if this is correct.

And the dll must have been compiled using the same operating system as yours. This is true, Yes?

[muze]

I had exactly this problem and was able to resolve it in the project settings:
switch General->Character Set from "Unicode" to "Not Set".