OK, the scenario…

I have a VS C++ program (a dll) that calls a static library (the static library uses Multibyte Character set)…

The static library calls a method from another dll (this dll uses Unicode Character set)…

I have the dll linked to the calling application through the linker property “Additional Dependencies”.

If I run the code, it will work as expected (which is unfortunately broken)… Now, I try to add a new method to the dll. I add the method prototype/declaration, rebuild it successfully, and move the new library to the path where the “Additional Dependencies” property expects it to be.

I then add a CALL to the new method and rebuild the static library. The static library BUILDS successfully.

I then rebuild the calling application. It fails with a LNK2019 error, unresolved symbol on the new method. Why could this be? The method added in the dll is modeled after an existing method so its form should be correct. The path for the dependencies has not changed and the new library is in that folder.

Any ideas? Thanks.
I guess I could add for clarity:

The function in the dll looks like this -

Code: [Select]

MyObj* MYCLASS::funct1(std::string str1, std::string str2, long var1, long var2, std::string str3)
{
MessageBox(0, s2ws(str1).c_str(), L"String 1 Value", 1);
MessageBox(0, s2ws( str2).c_str(), L"String 2 Value", 1);
MessageBox(0, s2ws(str3).c_str(), L"String 3 Value", 1);

// Code to return the object is here.

}


where function s2ws is defined as (found online) -

Code: [Select]
std::wstring s2ws(const std::string& s)
{
int len;
int slength = -1;

len = MultiByteToWideChar(CP_ACP, 0, s.c_str(), slength, 0, 0);

wchar_t* buf = new wchar_t[len];
MultiByteToWideChar(CP_ACP, 0, s.c_str(), slength, buf, len);

std::wstring r(buf);

delete[] buf;
return r;
};


This results in mangled names being displayed for the string values even though they are correctly passed into the function. I was wondering if this was due to the differences in the character sets being used between the static and dynamic libraries. The next thing I wanted to try was to convert the strings to wide string before passing them into the dll.

So on the static side I took the strings and passed them to the s2ws function before passing them in and checked both versions there. They were correct. So next I needed a new function in the dll to take wstring values. It is pretty much the same as above -

Code: [Select]
MyObj* MyClass::funct1(std::wstring str1, std::wstring str2, long var1, long var2, std::wstring str3)
{
MessageBox(0, str1.c_str(), L"String 1 Value", 1);
MessageBox(0, str2.c_str(), L"String 2 Value", 1);
MessageBox(0, str3.c_str(), L"String 3 Value", 1);

// Code to return the object is here.

}


That gets me back to the scenario I described first. After rebuilding everything, I am getting the LNK2019 error.

Thanks...I can't say much to help, but I can say that changing the parameter types will change the mangled name that the compiler generates for a function, which will result in unresolved externals.

Aside from that I just wanted to post so at least you know you weren't being completely ignored...Thanks for the post BC... I just noticed the error in my post that may have led to your comment. The second function that I CREATED was not supposed to look like I was overloading the original. The prototype for that one is actually -

Code: [Select]
MyObj* MyClass::funct2(std::wstring str1, std::wstring str2, long var1, long var2, std::wstring str3);


- with a funct2 name and not funct1. And the mangling was coming before this. I was merely passing a std::string into the dll and trying to use it in a message box (which because it is a Unicode dll defaults to MessageBoxW).