Linking error while in C++/CLI project while wrapping C++ shared library

1
votes

I am trying to wrap C++ library to that managed projects can use it. The third party library I am using is a shared library. It's meant to link on load time. I have header files, .lib file which is DLL import library and .DLL file.

This is what I did so far:- 1. Created CLR project. 2. Added path for header file in C/C++->General->Additional Include Directories 3. Set 'Additional Library Directories' in Linker->General. 4. Added lib name in Linker->Input->Additional Dependencies

After I do that, I get LNK2005 linking error followed by LNK1169. The only thing I did after creating the project is including header file from C++ library which I am trying to wrap. What am I doing wrong?

error LNK2005: "public: virtual char const * __cdecl std::exception::what(void)const " (?what@exception@std@@UEBAPEBDXZ) already defined in ... fatal error LNK1169: one or more multiply defined symbols found

2
c++c++-clinativeword-wrap
Do you want to use the libraries statically or dynamically? – GKE
I am happy to use any way. What is prefer way of doing it in C++/CLI project? I am trying to use static way by using .lib file but getting weird LNK2005 error. error LNK2005: "public: virtual char const * __cdecl std::exception::what(void)const " (?what@exception@std@@UEBAPEBDXZ) already defined in .... – DSS
How is your library compiled and how are you currently trying to link it? Without seeing your code my best guess is that you compiled it statically and are trying to link it dynamically. As for the preferred way of doing it in a C++/CLI library, I'm pretty sure that's dependent on you and your needs, if i recall correctly there is no preferred way, as long as you aren't trying to dynamically link against a statically compiled library or vice versa. – GKE
You're getting these errors because you're trying to statically link a C++ library into a C# program. Have you tried making a Managed C++ Wrapper? prior? – GKE
I think the only way to answer this question would be to write a thorough tutorial and you should probably google for some. (That's not to say it's necessarily OT, but you'll probably be faster finding a real tutorial than waiting for someone to write it up here.) – Martin Ba

2 Answers

1
votes

Indeed, we were the creators of the library and after a long battle, we were able to figure out the issue. In case it's useful for somebody else, here goes the answer.

The library was being generated using CMake, and to avoid having to export symbols by hand (using __declspec(export), we simply turned on

set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS on)

However, doing that in a DLL implies that Visual Studio not only exports the symbols defined in the DLL itself, but also in its inherited dependencies (like the entire STL for example).

The previous (I'm not really sure why) is not a problem is you are linking this library as part of the building of an executable (as we do have a C++ EXE that successfully uses this DLL), but it's a major issue if you are linking the DLL against another DLL (which is the case for CLI/C++, where you're basically creating one DLL to wrap another DLL). In the latter, the CLI DLL will also try to import the symbols from the system, resulting in the redefinition previously displayed:

error LNK2005: "public: virtual char const * __cdecl std::exception::what(void)const " (?what@exception@std@@UEBAPEBDXZ) already defined in ... fatal error LNK1169: one or more multiply defined symbols found

One way to check this is to take a look of the export file (.def) generated by the base C++ DLL (not the CLI one), it contains std::exception::what (among many others), although that DLL never defined it by itself.

So the solution was rather simple:

  1. Turn off CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS.
  2. Export/import explicitly the desired symbols from the DLL (using __declspec(export|import).
0
votes

You are probably trying to link statically two different versions of the standard library. Have you checked with the third party provider of the library to determine what version of Visual Studio/C++ they used to build this library?

Also, when troubleshooting issues with third party libraries, you should try to link a simple command line executable before you try to build a C++/CLI library.

And yes, if possible you should statically link the native C++ library to your C++/CLI dll. It will make deployment easier. Presumably this will be the only C++/CLI assembly your C# app will use.