I am using a library cv_bridge (http://wiki.ros.org/cv_bridge) that defines a class Exception. This library depends on the library OpenCV which also defines a class Exception. Visual Studio 17 fails to build:
Error LNK2005 "public: __cdecl std::exception::exception(class std::exception const &)" (??0exception#std##QEAA#AEBV01##Z) already defined in cv_bridge.lib(cv_bridge.dll) my_project_name C:\my_project_path\MSVCRTD.lib(throw_bad_alloc.obj)
Error LNK2005 "public: virtual char const * __cdecl std::exception::what(void)const " (?what#exception#std##UEBAPEBDXZ) already defined in cv_bridge.lib(cv_bridge.dll) my_project_name C:\my_project_path\MSVCRTD.lib(throw_bad_alloc.obj)
I need to link OpenCV in order to link cv_bridge, but I don't see how I can get around this multiple symbol problem.
Is there a way around this issue aside from re-building one of the libraries? Maybe some VS17 build settings that I can configure to handle this?
Some more context: The cv_bridge package is part of the larger ROS framework, and I've used it many times within the ROS framework on Ubuntu. Now I'm trying to build a DLL in Windows to invoke from some C# code. Is it possible the ROS framework build system can bypass this issue in an ad-hoc way, and I just need to reproduce that in Windows somehow?
I don't think this issue is caused the the same defination of the class, since the two different exception classes are in different namespace.
You may try to change the configuration of the project, add the libraries to "Ignore Specific Library".
"Configuration Properties -> Linker -> Ignore Specific Library"
Add "msvcprtd.lib;MSVCRTD.lib" libraries.
Related
I have a legacy Windows project using the legacy 32 Bit C++ compiler. For various reasons I need to use the Windows 8+ function PathCchCanonicalizeEx. C++Builder seems to provide the header and some module definition file for that, but I can't find any library to link against:
[ilink32 Error] Error: Unresolved external 'PathCchCanonicalizeEx' referenced from C:\[...]\WIN32\DEBUG\TMP\FILE.OBJ
How am I supposed to fix this? Do I need to add a Windows 8.1 SDK? Is the necessary lib simply named differently and I can't find it? Something completely different?
According my tests, one has two options:
IMPLIB/MKEXP
I'm developing/testing a some Windows 10 21H2, which provides an implementation for PathCchCanonicalizeEx in some DLL already. So if that source DLL is known, one can use IMPLIB or MKEXP to create an import library manually. I did that and after adding the created library from IMPLIB to my project, the linker errors were instantly gone.
Though, it's not that easy to know where PathCchCanonicalizeEx is placed in. One pretty easily finds the api-ms-win-core-path-l1-1-0.dll, but that thing is NOT an actual file on the disk and therefore can't be used by IMPLIB or MKEXP. That name is only a virtual concept for the library loader to address the same named API set of modern Windows, the extension .dll doesn't mean it's a file at all.
You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names
What you really need to work with is KernelBase.dll, which is even documented by MS.
implib "KernelBase x86.lib" C:\Windows\SysWOW64\KernelBase.dll
implib "KernelBase x86-64.lib" C:\Windows\System32\KernelBase.dll
Module Definition File
The downside of manually creating LIB files is that one needs to maintain those with the project. Things depend on if the target is 32 or 64 Bit, DEBUG or RELEASE, so paths might become a bit complex, one might need to create relative paths for libraries in the project settings using placeholders for the target and stuff like that.
It seems that all of this can be avoided with Module Definition Files, which's purpose is to provide IMPORT and EXPORT statements to either consume exported functions by other DLLs or make that possible for others with own functions. I've successfully resolved my linker problems by simply creating a file named like my app using the extension .def alongside my other project files. That file needs to be added to the project, though.
dbxml.cbproj
dbxml.cbproj.local
dbxml.cpp
dbxml.def
dbxml.res
[...]
The following content made the app use the correct function from the correct DLL. Though, what didn't work was using the API set name, which resulted in an error message by the linker.
IMPORTS
KernelBase.PathCchCanonicalizeEx
IMPORTS
api-ms-win-core-path-l1-1-0.PathCchCanonicalizeEx
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
[ilink32 Error] Fatal: Error processing .DEF file
The latter is after restarting C++Builder, so I guess the format of the file is simply wrong because of the API set name.
I'm trying to port one of my iOS apps from the Mono versions of the
ServiceStack.Text libraries to the PCL versions for JSON
serialization/deserialization.
I have the libraries working in a regular Windows console application. When trying to port this into the iOS application, I'm getting an "Object reference not set to an instance of an object" exception from on the ServiceStack extension method classes. The error message is a red herring; the true error is getting swollowed by a try/catch.
The static constructor in ServiceStack.Text.PCL.PclExport is doing late binding for a
platform specific DLL and can't find that DLL. The build log bears out that the
Client, Interface, and Pcl libraries aren't being packaged with the .app file even though the reference are included at the project level.
I've been able to reproduce this in a basic iOS Hello World application. If I
add a line of code that references a method in the Pcl DLL, the three missing
libraries are copied. However, I'm still getting the same "Object reference not
set to an instance of an object" error.
I suspect that this is caused by the fact the Xamarin compiler doesn't translate the DLLs into iOS binaries unless they are actually used, and since they're late bound, it doesn't know they're used and so ignores them.
I didn't think late binding was legal under the licensing on at actual iPhone? doesn't the link merge everything into one exe?
See the Xamarin Linker Docs try the -nolinkaway option.
I have two projects in an F# solution.
1. main project with [EntryPoint] and set as the StarUp project.
2. support, the second project, holds a group of support modules. I.e. they are only called and never initiate anything nor serve as the entry point nor are the StartUp project.
For the last module in the support project, compiling in Visual Studio gives
warning FS0988: Main module of program is empty; nothing will happen
when it is run
While using compiler option nowarn inline as #nowarn "988" in the module causing the warning does suppress the message I would rather add something like a dummy function with comments that resolves the issue.
How does one make such a dummy function to resolve the warning?
EDIT
Jack is correct in that my support project was setup as a Console Application instead of a Class Library. Changing to Class Library resolved the warning. It is also nice to know about do () for the other case.
EDIT
While it seemed odd that I would have set a support project as a Console Application, I recently found that for some reason when I made a change to the code in the project, something changed the Output type from Class Library to Console Application. I suspect it has to do with the F# PowerPack and it's build rules, but it's only a guess.
Are you building the support project as a Library or as a Console Application? (This is set via the project properties page.)
If you're building it as a library, then you may need to add a do() at the end of the last file in the project. This is necessary to make the F# compiler happy in a few specific scenarios, like when you create a module which contains only assembly-level attributes (because they're applied to the assembly, the module appears "empty" to the compiler).
You can see an example in my code here:
https://github.com/jack-pappas/FSharp.Compatibility/blob/master/FSharp.Compatibility.OCaml/AssemblyInfo.fs
I've spent the last hour or two trying to hunt this problem down and can't seem to get it right. I am using OpenCV with MS VS 2012 RC, and to this point it has worked quite well (one bug dealing with the newer Mat container, but fine otherwise). I have a previously written application I am trying to port (from GCC/G++), which used the cvblob.dll library from here. I have recompiled the cvblob library with VS2012 (my previous version was compiled with MinGW and worked flawlessly), and managed to create both a DLL and an import library .LIB.
The application compiles properly, but the one spot where I use the cvblob library is now my source of error, because the linker cannot find the symbol for the cvLabel function in the library. This is the complete error message I get from VS2012:
ConsoleApplication1.cpp
1> Generating Code...
1>imageinput.obj : error LNK2019: unresolved external symbol _cvLabel referenced in function "public: class std::vector,class std::allocator > > _thiscall ImageInput::getROI(class cv::Mat,class cv::Mat)" (?getROI#ImageInput##QAE?AV?$vector#V?$Rect#H#cv##V?$allocator#V?$Rect_#H#cv###std###std##VMat#cv##0#Z)
1>C:\Users\Jake\Documents\Visual Studio 2012\Projects\ConsoleApplication1\Debug\ConsoleApplication1.exe : fatal error LNK1120: 1 unresolved externals
I'm not certain whether this is a problem with the cvblob library itself, my current binary for it, or just the process I used to compile it. I will gladly furnish any information I can upon request. Thanks in advance for your advice!
You obviously didn't link needed library in project settings. Try to add all OpenCV/CvBlob libs in linker properties of your prooject. See docs.
Also look at this discussion.
So I've got a Visual studio 2005 solution that contains a C# project (test driver - creates exe) and 7 C++ Projects (dll's).
This solution builds fine up to this point.
I have DevPartner studio 8.2 installed. I am trying to generate test coverage on the entire solution which requires me to instrument native c++ code during builds. when I turn this DevPartner option on, the build produces linker errors.
Does anyone have experience with this?
For example:
Error 25 error LNK2001: unresolved external symbol "public: __thiscall IntLong::IntLong(class BufObjBase *,int,int,unsigned char,wchar_t const *,bool)" (??0IntLong##QAE#PAVBufObjBase##HHEPB_W_N#Z) X.obj
A co-worker figured this out.
In case anyone else runs into this problem:
There is a dependency chain in the project between dlls, other dlls, and libraries. Under a normal build, visual studio is smart enough to find the libraries. With DevPartner inserting its instrumentation, it isn't.
Make sure all additional dependencies are explicitly specified in (properties on project getting the link error) -> Linker -> input -> Additional Dependencies.