Unresolved externals and wchar_t's

I'm getting the following errors when compiling my program in VS2005b2. This program uses a 3rd party static lib and associated header files, so I can't change them. I think it was originally compiled in eVC++4.0.

Error 1 error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl CL2CapIf::SetSecurityLevel(wchar_t *,unsigned char,int)" (__imp_ SetSecurityLevel@CL2CapIf@@QAAHPA_WEH@Z) referenced in function __unwind$66570 STPStack.obj

Error 2 error LNK2019: unresolved external symbol "__declspec(dllimport) public: enum SDP_RETURN_CODE __cdecl CSdpService::AddServiceName(wchar_t *)" (__imp_ AddServiceName@CSdpService@@QAA AW4SDP_RETURN_CODE@@PA_W@Z) referenced in function __unwind$66570 STPStack.obj

They are defined like this in the header:

#define BT_CHAR TCHAR
BOOL SetSecurityLevel (BT_CHAR *p_service_name, UINT8 security_level, BOOL is_server);
SDP_RETURN_CODE AddServiceName (BT_CHAR *p_service_name);//CE defs

I'm calling the functions like this:

static wchar_t m_serviceName[] = _T("SimTools Protocol Service");
m_pSdpService->AddServiceName(m_serviceName);
CL2CapIf::SetSecurityLevel(m_serviceName, (UINT8) BTM_SEC_NONE, (int)isServer);

I'm calling plenty of other functions from the library, but these are the only two that pass a TCHAR (i.e. wchar_t). I do have UNICODE and _UNICODE defined.

Any suggestions would be greatly appreciated.
Thanks,
Cyle

Answer this question

Unresolved externals and wchar_t's

Medezark
I think I've found the solution in this thread...

http://forums.microsoft.com/msdn/ShowPost.aspx PostID=92048
Tomo-hawk
Wow, an actual answer that even seems correct, and in under an hour! I'm very impressed.

However, I'm also a little confused by how to implement the solution. What did you mean by "using /Zc:wchar_t- on the .cpp files" don't you compile the whole project with one set of flags What do you mean by "isolate the calls into a separate file"

Sorry, but I'm kinda new to compiler nuances.

Thanks,
Cyle
taia_gen
The errors you got on the APIs were a consequence of the /Zc:wchar_t mismatch problem I was trying to warn you about (but wasn't explicit enough).

Visual Studio lets you set C/C++ settings per-file, which is what I was recommending you do with /Zc:wchar_t- instead of setting that flag for your entire project. Also, note that setting "Treat wchar_t as Built-in type" to NO (as per the other thread) is the same thing. My apologies for referring to the actual compiler flag and forgetting that the Settings UI appears differently.

In general the rule is that you must have parity in the definition of wchar_t between libs and the cpp file you're compiling. That is: If a symbol contains that native wchar_t (i.e. built with /Zc:wchar_t), then the file that includes the header prototype of that function must be built with /Zc:wchar_t. This is so that the caller (your app) and callee (the library) both agree on the name decoration of the symbol. This rule applies vice-versa: if the symbol uses the typedef'd wchar_t (unsigned short), then the file must use /Zc:wchar_t-.

But what I am fearing is that your cpp file is calling both the legacy lib *and* current CE libs. The former was built with /Zc:wchar_t- and the latter built with /Zc:wchar_t. This makes parity impossible until you split the cpp file into two parts. i.e. you consolidate the the legacy-lib calling code into its own cpp file and that is the only file in which you throw the /Zc:wchar_t- switch.

Yes, the thread you give is the same situation, and while I am not seeing a clear solution stated therein, if it helped, I'm glad.

Brian

Torpedo

Brian Kramer wrote:

...

But what I am fearing is that your cpp file is calling both the legacy lib *and* current CE libs. The former was built with /Zc:wchar_t- and the latter built with /Zc:wchar_t. This makes parity impossible until you split the cpp file into two parts. i.e. you consolidate the the legacy-lib calling code into its own cpp file and that is the only file in which you throw the /Zc:wchar_t- switch.

Brian

Is there a solution to this problem I'm in the same situation. I need to call code that is compiled with wchar_t as a native type AND treated as an unsigned short**. Is there anyway I can use typecasts

misterface
Yes, you can cast away the problem by providing wrapper methods. Here's a bug I opened where Microsoft says they're aware of the issue but fixing it does more harm than good.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx FeedbackID=100186
Leao
Ok, I changed the "Treat wchar_t as built in type" setting in my project compiler properties. Now I'm getting lots (13) unresolved externals, but they are all "system type things" like: CWinApp, SetRegistryKey, Create, CreateEx, CStringT, CSimpleString, CListBox::AddString

I'm obviously mixing apples and oranges, but I don't know where.

Thanks,
Cyle
xopher
The compilers in Visual Studio 2005 now enable /Zc:wchar_t by default, as to be ISO C++ conformant. /Zc:wchar_t makes the wchar_t keyword map to its own native and unique type, and its opposite, /Zc:wchar_t-, makes wchar_t a typedef of unsigned short (making it not-so-safe in the eyes of the compiler type-checking).

See http://msdn2.microsoft.com/en-us/library/h4bcz65t for a list of changes that includes /Zc:wchar_t.

The solution to your problem is to use /Zc:wchar_t- on the cpp file(s) that #include the prototype of and call these two functions. Note that since the libs that ship with VS 2005 are probably using the default /Zc:wchar_t, you might have to isolate the calls into a separate file. (I raised this issue some time ago, and I wonder what the status is on this kind of scenario.)

Brian

PS In case you didn't know there is also a forum that deals specifically with Native C++ development for Smart Devices.
Asan
I changed the header for my 3rd party library so the functions expected unsigned shorts (I'm presuming this is how the lib was compiled using eVC4), and left my project the new (default) way (with wchar_t as its own type).

This seems to have worked - I only had 3 such references in my library, so it wasn't a big deal.

Thanks for your help Brian, you pointed me in the right direction. I've been stuck on this for weeks.

Cyle
Unresolved externals and wchar_t's

Answer this question