I have an error in compiling a project.
I'm trying to link to a library I have on windows, using visual studio.
When trying to create the obkect (with new), I get the following error:
Error 2 error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##QAE#XZ) already defined in RMLibV053.lib(Inifile.obj) msvcprtd.lib
I used #ifndef
I used disable warning
It may be that your code is set up to use a different run-time environment (single-threaded, multi-threaded, multi-threaded DLL) than your PTLibV002.lib library when it was built.
If PTLibV002.lib was compiled to use C++ library statically linked and your binary uses C++ library as DLL, then this is the linking error you'd receive. This is because PTLibV002.lib will contain the definitions of functions from STL it uses, and your binary contains another definition pointing to the C++ library DLL.
probably you added a similar library to additional libraries.
As Ferruccio explained before.
I used on the visual studio configuration of project: compiled with the setting to use the dynammic linked run time library : Multi-threaded Debug DLL (/MDd) instead of Multi-threaded Debug (/MTd).
Related
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
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:
Turn off CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS.
Export/import explicitly the desired symbols from the DLL (using __declspec(export|import).
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.
I am adding .dll to C++ project.
IDE: Visual Studio 2013
What I did:
Added directory with headers to VC++ Directories -> Include Directories
. It's ok, I can include headers, IntellySense sees names
in these files.
Added .lib file to Additional Dependencies section and a path to this
file in both VC++ Directories -> Library Directories and Linker -> General -> Additional Library Directories.
Placed actual .dll file to DEBUG folder (also to project folder, just
to be sure)
Used dumpbin.exe to get sure I have exported all needed classes in my
.dll
And I still get a bunch of unresolved externals with functions stored in that .dll. Any suggestions?
I found this question and set Use library Dependency Inputs to Yes. Still no luck.
Some more info:
Error example:
Error 2 error LNK2019: unresolved external symbol "__declspec(dllimport) public: double __thiscall Fem::Node::GetX(void)" (__imp_?GetX#Node#Fem##QAENXZ) referenced in...
This function in dumpbin output:
172 AB 000F81A0 ?GetX#Node#Fem##QEAANXZ
I see some difference in the last part of the name. Somehow, as I mentioned in the comments, I got it working in Qt project with Visual Studio compiler.
This is usually a bad idea, since it doesn't lead to a reusable library. The application can't be rebuilt with a new compiler or even new compile settings without also rebuilding the DLL. It is safer to just compile the classes you use in statically. That said, there are some benefits if used in conjunction with delay-loading, so...
In order to store a class implementation in a DLL, while building the DLL you must use __declspec(dllexport) on the class, and when consuming it there must be __declspec(dllimport). Import libraries have shims to forward free function references to DLLs but those don't work for classes and class members.
Usually macros are used to accomplish the switch between dllexport and dllimport.
Now that you've shown mangled names, the difference becomes apparent, and demangling gives a clue to where the problem came from.
Linker is looking for
public: double __thiscall Fem::Node::GetX(void)
But DLL is exporting
public: double __cdecl Fem::Node::GetX(void) __ptr64
Notice that the calling conventions are different; if this had linked, you would have crashed as soon as you tried to call this function.
You cannot use exports from a DLL that have C++ signatures from an application compiled differently. Are you mixing architectures (x86 vs x86_64 vs ARM)? Can't do that either, not even using highly-compatible C calling signatures.
I'm trying to get around these link errors:
error LNK2001: unresolved external symbol "__declspec(dllimport) public void __thiscall std::basic_ostream(char,struc std::char_traits<char>>::_0sfx(void)"
I used Visual Studio C++ 2010, and tried with Visual Studio C++ 6.0, but still the same errors show up.
The object file is found, so I am suspecting that it cannot find the implementation of the std library? I've tried /nodefaultlib option on a few libraries (libc.lib, libcmt.lib, msvcrt.lib, etc) but did not improve the situation at all.
Could someone explain why the error occurs and where I should look ?
Tried the solutions suggested in other similar questions but they either are not applicable or do not resolve the problem.
Thanks
You should remove /nodefaultlib option.
This problem could arise if some of your libraries are linked static while other dynamically.
Basically if you have both codes compiled with the static version of CRT (that's compiler switch /MT and /MTd) and dynamic version of CRT (switch /MD, /MDd).
You can see what your project is using in Project Properies - c++ - Code Generaion - Runtime Library)
Make sure all your libraries are compiled with the same switch as you project.
I have written an application in VS C++ 2010 Express Edition which consists of some DLLs and also depends on some third party DLLs.
The application itself is a DLL.
As it turned out, to make it work on another machine, user has to install VS 2010 redistributable runtime.
I tried to build my DLL with flag /MT instead of /MD - I believe this means that I want static linking.. However, in this case I got 'multiple definition' errors about MSCVRT.lib. Error message also suggested to use flag /NODEFAULTLIB:msvcrt.lib to avoid this. However, with these settings my application still requires runtime installation.
Could somebody please explain me how to avoid this?
Thanks,
Robusta
Update: if I simply use /MT flag instead of /MD I get the following error
MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info##AAE#ABV0##Z) already defined in LIBCMT.lib(typinfo.obj)
MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info##AAEAAV0#ABV0##Z) already defined in LIBCMT.lib(typinfo.obj)
Creating library C:\MyApp\Release\MyApp.lib and object C:\MyApp\Release\MyApp.exp
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
C:\MyApp\Release\MyApp.dll : fatal error LNK1169: one or more multiply defined symbols found
after adding flag /NODEFAULTLIB:library I get no errors, application is built successfully, but still requires runtime installation.
Is it possible that 3rd party libraries, which I also link, require runtime?
You are linking in some code that is still compiled with /MD, possibly some kind of static library. Mixing and matching doesn't work.
Using /MT when you use DLLs is very dangerous. You'll get in trouble when the exported functions return a pointer or a C++ object that needs to be released by the client code. Returning an std::string for example. With /MT, the client will use its own heap allocator to release the memory. Cannot work, the DLL used another heap. You'll leak, very hard to diagnose. Using 3rd party DLLs that were built with a different version of the CRT is a problem for the same reason. There's more details in this MSDN Library article.
Deploying the required CRT DLLs is pretty simple with this download.
I've a VS2008 native C++ project, that I wish to compile as a DLL.
It only references one external library (log4cplus.lib), and uses its functions.
(also uses log4cplus's .h files , naturally).
When I try to compile my project as a static library, it succeeeds.
When I try as DLL, it fails :
1>MessageWriter.obj : error LNK2019: unresolved external symbol "public: static class log4cplus::Logger __cdecl log4cplus::Logger::getInstance(class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > const &)" (?getInstance#Logger#log4cplus##SA?AV12#ABV?$basic_string#_WU?$char_traits#_W#std##V?$allocator#_W#2##std###Z) referenced in function "class log4cplus::Logger __cdecl Log(void)" (?Log##YA?AVLogger#log4cplus##XZ)
There are 4 more errors just like this related to functions within log4cplus.lib.
It seems like something really stupid.. please help me :)
Thanks!
Edit :
I am linked against the log4cplus.lib file, and it finds it just fine.
also, the log4cplus.lib is 100% functional, I am using it in another project with no problems.
My original intention was to compile my project as a static library and use it in another DLL I am writing, but when do this, I get the same linker errors in that other project...
Edit #2 :
The functions which cause the linker errors are static functions.. could this be part of the problem?
wilx is right.I have the same link problem.
it took me almost one day to slove this issue.
I have downloaded log4cplus-1.0.4, after I opened this project with visual studio 2010,compile it, both static and dynamic library, no error.
however, when I try to use those library, I got a link error,no matter static library or dynamic library.
the reason is,by default, those project use multi-byte character, however, my own project use unicode,so,to slove those link problem, you just need to change one project's charset.
both unicode or both multi-byte charset.
and to change one project's charset in visual studio 2010,
see the following link.
How do I turn off Unicode in a VC++ project?
When you're creating a static library, the library creator does not try to resolve all the functions that you are using (the ones that are in log2cplus.lib). These functions are resolved when you create an executable that links with your static library.
When you're creating a dynamic library, the library creator (the linker) does try to resolve all the functions you are using. You have to provide the linker with the log4cplus.lib library as soon as you build the dynamic library. You cannot wait until you create the executable.
In either case you need to link against library.
Difference is that when you link statically - all functionality is linked via library you're using.
When you're linking dynamically you link against import library which have functionality to load and use functions from dll and this step you're missing. Usually import library have the same name as the dll you're linking against.
Edit:
I saw it that missing symbol is not '__imp...'
This means that header file is not "configured" for dynamic linkage, probably because you have LOG4CPLUS_BUILD_DLL or log4cplus_EXPORTS or DLL_EXPORT not defined in project where you include Log4Cplus headers.
Are you actually linking with the log2cplus.lib file? If you were compiling as a static library then you would link to it via the final .exe and not in the static library - perhaps that is the difference?
Did you use __declspec(dllimport) and __declspec(dllexport)?
They are not necessary when linking static libraries, but required for DLLs. The function has to be declared for exporting (in the DLL), so users can use it outside (and thus import it from the DLL).
Maybe this can help:
Importing into an Application Using __declspec(dllimport)
http://msdn.microsoft.com/en-us/library/8fskxacy%28VS.80%29.aspx
best regards
If you're using a compiler like MSVC, then it may have changed the project settings without you knowing about it when changing from lib to dll. You should double-check that in DLL mode, you are properly linked to the lib.
There are two possibilities that I can see for the linker error:
You have compiled the log4cplus.dll (and the associated log4cplus.lib import library) using the provided Release build configuration but now your application is compiled with "Character Set" option set to "Use Unicode Character Set"
Or you are trying to use log4cplus' static library but defining LOG4CPLUS_BUILD_DLL for your application.
I bet on number 1. It could be something else, still. What version of log4cplus are you using?
If you want to use log4cplus.dll in your application, define the LOG4CPLUS_BUILD_DLL symbol. log4cplus_EXPORTS and DLL_EXPORT are there only to support the CMake based build system, and autotools based build system on MingGW respectively.