My solution has 3 projects:
native C++ (static lib)
CLI/C++ wrapper (dynamic lib)
C#
In my native C++ project I have some image processing using opencv 3.2. My CLI/C++ project manages the communication between C++ and C#.
As long as I'm in debug mode, I have no trouble, but when I switch to release mode I get a lot of LNK2001 "unresolved external symbol" errors for the opencv functions.
For both, debug and release, I'm using property sheets for opencv and both of them definitely work (I use them in multiple projects). My native C++ project builds in both modes successfully but the build crashes on the CLI/C++ wrapper (this project uses some opencv functions itself).
I already validated the property sheets (corret libs, paths are set).
Maybe there are some additional rules I have to care about in CLI/C++?
Edit
I'm using C++17 with Visual Studio 2017 on Windows 10.
Related
I am new to programming in C++ on Universal Windows Platform and I have a quick question: I created a project of Static Library (Universal Windows) in Visual Studio 2015 but I couldn't use those Windows Runtime classes such as Windows::UI::Core::CoreWindow in that project.
I guess I need to add include directives or references to libraries but I couldn't find information about that. I tried to search MSDN but just found two pages where two headers were mentioned for namespace default and Collections.
Does anyone know how to reference Windows Runtime classes in a Static Library?
You need to build the project with the /ZW option to allow consuming Windows Runtime Extension in a UWP Static Library:
Right click on the project from Solution Explorer
Click Properties
Select C/C++ -> General
Set the "Consume Windows Runtime Extension" to "Yes(/ZW)"
Click OK
After applying this option, references to Windows Runtime Extensions appear under the references of the project and you can use Windows Runtime Classes.
However, you may see a linker warning while building the library:
Debug\pch.obj : warning LNK4264: archiving object file compiled with
/ZW into a static library; note that when authoring Windows Runtime
types it is not recommended to link with a static library that
contains Windows Runtime metadata if you are using a linker released
before VS 2015 Update 2
I tested the scenario and it worked fine in debug mode, however, I'm not sure if it is the best way since the /ZW option is off by default unlike other types of UWP projects.
MSDN:
You can use a native C++ static library in a UWP project, but there
are some restrictions and limitations to be aware of. Start by reading
this topic about static libraries in C++/CX. You can access the native
code in your static library from your UWP app, but it's not
recommended to create public ref types in such a static library. If
you compile a static library with the /ZW option, the librarian
(actually the linker in disguise) warns:
Maybe you should consider wrapping all the code in a Windows Runtime Component or a UWP DLL instead.
I am trying to implement lua into C++ however I am having problems with Visual Studio saying that I have an unresolved external symbol called "_sprintf", "_fprintf", and "__iob_func".
I'm pretty sure that these functions exist in C++ since I have seen (well the first 2) them used before.
You're probably running into the C-runtime changes introduced in VS2015: The Great C Runtime Refactoring.
You can add the following library to supply those definitions in the Additional Dependencies in the Project Settings -> Linker -> Input:
legacy_stdio_definitions.lib
I recently got assigned to a c++ project, although I am not a c++ developer. I was provided Visual Studio 2010 Professional as IDE. So I gave it a shot.
I am to write a c++ dynamic library (*.dll) which wraps two static libraries (*.lib). The static libraries are third party libraries we bought a couple of years ago from another company. Using the dumpbin /header ... cmd call, I can say that both static libraries have the following file header value:
14C machine (x86)
I got this task working for the Win32 solution platform. I added the header files and the libraries to the project. The libraries are included by writing two #pragma comment(lib, ...) statements within the .cpp I need the functions in. Works like a charm. A sample function looks like this:
extern "C" void OURFreeStringBuf(Cm_StringBuf *sbuf)
{
FreeStringBuf(sbuf); // the call to the static library
}
This dynamic library is to be used in x64 architectures, aswell. So I tried to set the solution platform to x64. Now I get the following error for each call of one of the static libraries' functions (no code changes or other configuration changes were made):
error LNK2001: unresolved external symbol "..."
followed by a summarizing error:
error LNK1120: 29 unresolved external links
Could these errors be the result of trying to link x86 lib files in a x64 dll? Is there any chance to complete this task using the provided static libraries?
Thank you very much in advance.
You can not - in other words, there is NO WAY to - link a 32-bit library with a 64-bit executable or DLL (or a 32-bit executable to a 64-bit DLL or vice versa). You will either have to compile your .DLL/.EXE as 32-bit, or find a 64-bit version of the 32-bit library. No other solution!
The 64-bit architecture is different from the 32-bit architecture in several aspects, but most importantly, the addresses (pointers) are 64-bit in a 64-bit architecture, which prevents almost any 32-bit code from working correctly in a 64-bit environment (because the upper 32 bits of the addresses are lost, which doesn't produce anything meaningful).
I have a problem writing wrapper program to use vendor's library in .Net client program(C#).
What the vendor provided are C++ header file and MFC static library file(.lib) built on both release and debug.
The problem is, when I build wrapper program, Visual Studio 2012 spits LNK error out like this:
error LNK2001: unresolved external symbol ___argc nafxcwd.lib(appcore.obj)
error LNK2001: unresolved external symbol ___argv nafxcwd.lib(appcore.obj)
I set up build property with option /clr,
set runtime library as Multi-threaded debug DLL (/MDd),
set using MFC as MFC in shared DLL,
ignored libraries(nafxcwd.lib;msvcrtd.lib;msvcmrtd.lib;libc.lib;libcmt.lib;msvcrt.lib;libcd.lib;libcmtd.lib, see this),
added dependencies(nafxcwd.lib;msvcrtd.lib;msvcmrtd.lib;(vendor's library), for CRT, MFC library order).
What I missed?
I don't know I described enough. If something is ambiguous, please ask to me.
Thanks in advance!
ps. I'm very new to C++(even Visual Studio..). I'm more familiar with Java.
I'm trying to parallelize our build process in Visual Studio 2005 to take advantage of our multi-core hardware. Simplifying things a bit, I've got two DLLs and an application. DLL A has no dependencies. DLL B uses certain functions defined in DLL A. The application uses functions defined in both.
I thought I should be able to build A and B in parallel, because you shouldn't need to resolve symbols until you link the application. However, when I remove DLL B's project dependency on A, I get errors like the following:
YFindReplaceWidget.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual unsigned long __thiscall CORBBaseComponent::GetRefCount(void)const " (__imp_?GetRefCount#CORBBaseComponent##UBEKXZ)
Is there a way to resolve these errors so I can build these DLLs in parallel?
That's... a really weird thought pattern. DLL's are nothing but EXE's with a different extensions, they need full linking information to be built.
As long as your build is a chain like that (app->b->a), they can't be built in parallel.
Microsoft officially introduced a multiprocessor built option in VS2008. It will allow the build to start multiple compilers for the same project. The easy solution is just upgrade to the latest version of Visual Studio.
If you are stuck on VS2005, then it is actually available there as well, but not officially supported. Just add /MP as an additional compiler option.
http://blog.280z28.org/archives/2007/10/17/ (Advices you NOT to use it on your buildserver)
http://msdn.microsoft.com/en-us/library/bb385193.aspx