I've searched around here and a few other sites and still the linker error I'm having doesn't seem to be in there or my reading comprehension is failing me today.
The errors VS2010 is giving me are as follows:
Error 10 error LNK2001: unresolved external symbol "void __stdcall
_com_issue_error(long)" (?_com_issue_error##$$FYGXJ#Z)
Error 11 error LNK1120: 1 unresolved externals
I cannot seem to find anywhere what function is missing its external so I know what I should be importing or at the very least including in the linker so debugging it is proving a little hard.
Didn't even think to add this, but when I try and add comsupp to my linker I get the following errors (also my link.exe actually crashes and asks me if I want to send a debug report to Microsoft):
Error 15 error C1001: An internal error has occurred in the compiler.
Error 16 error LNK1000: Internal error during IMAGE::BuildImage
Do include comdef.h, but don't include comutil.h
Project Property ->Linker -> Input ->Additional Dependencies.
Add comsuppd.lib (or comsuppwd.lib) if it's debug mode.
Add comsupp.lib (or comsuppw.lib) if it's release mode.
Related
I'm working on a Windows KMDF driver using VS2019, where I need to use the SerCx2 framework.
Although, if I use #include <sercx.h> I get "No such file or directory".
If I use #include <sercx/2.0/sercx.h> the compiler finds the header file, but instead there are linking errors:
Error LNK1120 2 unresolved externals KMDF
Driver1 C:\Users\dev\source\repos\KMDF
Driver1\x64\Debug\KMDFDriver1.sys 1 Error LNK2001 unresolved external
symbol SercxDriverGlobals KMDF Driver1 C:\Users\dev\source\repos\KMDF
Driver1\KMDF Driver1\Driver.obj 1 Error LNK2001 unresolved external
symbol SercxFunctions KMDF Driver1 C:\Users\dev\source\repos\KMDF
Driver1\KMDF Driver1\Driver.obj 1
I have tried manually adding the folder containing sercxstubs.lib as an additional library directory in linker settings, but that makes no difference.
Anyone here who has worked with SerCx2 and has an idea what might be the issue?
It seems as there should be somewhere in the settings to configure SerCx (for example, choose between version 1 and 2). But I can't find it anywhere.
I tried to use a library about date time conversion in this website. However, when compiling it, errors occur:
ERROR 1 error LNK2019: mod_datetime.obj
ERROR 2 error LNK2019: libifcoremdd.lib(for_main.obj)
ERROR 3 fatal error LNK1120: 2 x64\Debug\datetime.exe
There are some similar questions (this or this), but they seems not about this "libifcoremdd.lib" problem. I find libifcoremdd.lib in my computer(C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\ia32 and C:\Program Files (x86)\Intel\Composer XE 2013 SP1\compiler\lib\intel64), why the link process failed?
Expanding on a comment I gave above - the quoted error text omits crucial pieces of information, that being the names of the symbols the linker was unable to find. (LNK2019 is "unresolved reference"). While it's unclear what ERROR 1 is referring to, ERROR 2 is due to your taking the library sources and building them in an executable project type. This causes the linker to look for a symbol _MAIN__ (for 32-bit) that is the Fortran main program. If there is none, then you'll get a LNK2019 error naming for_main.obj in the Intel Fortran run-time library.
The solution is to create a new project in Visual Studio of the "Fortran Static Library" type, so that a main program is not expected.
We have a project which is an executable, which loads DLL files at run time as plugins.
We're trying to make a new plug in which has many library dependencies, and some of those dependencies are the same library but different versions that other plugins link to.
Because the libraries are depended on by different plugins at different versions, I would like to statically link/build any dependencies into the new plugin - that way they can't conflict with the old plugin dependencies. As far as I know, nothing in the dependencies of the plugin need to be exported, they're just used by the plugin.
Is it possible to do this?
I've tried building all the static libs in visual studio as static libraries with the runtime set to Multithreaded DLL with the /MD flag, but when I try to build dynamiclibB.dll, I get linker errors. If I set dynamiclibB to build as a static library, it doesn't have the linker errors.
I haven't tried linking newplugin.dll to the static library version of dynamiclibB yet, but I think I have exactly the same situation, so I see no reason why it would work there where it doesn't one level down.
I don't want to build dynamiclibB as a static library anyway, as it would be good to be able to update newplugin.dll without including dynamiclibB.dll if it hasn't been changed, as in, to decouple the update process. This line of reasoning would suggest that I should have .dlls for everything, but the conflicts of versions is what worries me, I think.
I cannot build the plugins as static libraries as they need to be loaded at run time.
Absolutely everything is being built in release mode for now, to avoid that complication.
What am I missing?
An attempt at a diagram that might help understand the situation:
program.exe
|
________________
| |
oldplugin.dll newplugin.dll
| |
dynamiclibA.dll dynamiclibB.dll
|
_________________________
| | |
staticlibA.lib slibC.lib slibD.lib
Update:
Providing some more information now that I know what's happening, and know that more specific details are actually relevant.
So library A, represented by dynamiclibA and staticlibA was zlib.
The library we were compiling (dynamiclibB) for use in the newplugin was PoDoFo.
The error messages we got were:
Error 19 error LNK2001: unresolved external symbol
_deflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 20 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 21 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngread.obj) podofo_shared Error 22 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 23 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\libpng16.lib(pngwutil.obj) podofo_shared Error 24 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 25 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngwrite.obj) podofo_shared Error 26 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 27 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared Error 28 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 29 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared
Putting the rest in an answer.
In my question, slibc.lib was libpng. Libpng also requires zlib, but it builds it from source inside its solution. We were able to use the output of that project in the way we desired, as in, zlib.lib built with /MD flag, without linking errors.
We've also managed to work out why this problem occurred:
another stackoverflow question was very relevant: https://stackoverflow.com/a/6559315/78823
Turns out that zlib has a #define ZLIB_WINAPI which defined the call convention to be STDCALL, which I don't understand, but it caused the linker errors. The other answer suggests to remove the define, and I suppose that's what libpng did with its zlib project.
I'm guessing that the reason why the linker errors only occurred when building the .dll and disappeared when building the .lib is because (correct me if I'm wrong, I don't fully understand this), build a .lib doesn't actually do the linking to the required functions, so would have been just passing on the linker errors to the next level up; I think we would have seen the same errors (but in different objs/projects perhaps) when compiling newplugin.dll, but we didn't get far enough to check that before we tried other things.
I'm trying to use the WMI example from msdn:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384724%28v=vs.85%29.aspx
I've copied the last set of code there verbatim into a console application in VS2008. If I have the application in release or debug for the win32 platform, it compiles (and runs) fine. If I have it in release or debug for the x64 platform, I get the following linker errors:
CppConsole.obj : error LNK2001: unresolved external symbol IID_IWbemConfigureRefresher
CppConsole.obj : error LNK2001: unresolved external symbol CLSID_WbemRefresher
CppConsole.obj : error LNK2001: unresolved external symbol IID_IWbemRefresher
CppConsole.obj : error LNK2001: unresolved external symbol CLSID_WbemLocator
CppConsole.obj : error LNK2001: unresolved external symbol IID_IWbemLocator
fatal error LNK1120: 5 unresolved externals
I've already tried putting the wbemuuid.lib into the linker input directly in the project properties, but that didn't make a difference from the pragma.
Has anybody made this work with x64? Or is there something else I'm doing wrong?
I give credit to RRUZ for this, as he/she at least put me on the right track, but as they haven't posted an answer-answer (just a comment) I can't click them for credit.
Basically, because of the work environment I'm in, the project directories are set up in a "non-standard" way. There was already a copy of wbemuuid.lib in another directory that was not the correct version (not x64), and that directory was higher on the library include list, thus never getting to the right Windows Platform library directory.
So if you ever have problems with x86 vs x64 and library includes, check your directories and check the ORDER of them as well.
I'm working on a project that already contains the gzip library as follows:
zlib\zlib.h
zlib\zlib.lib
zlib\zconf.h
I would like to use the gzip functions from this .lib but am getting the following errors:
Compress.cpp
Linking...
Compress.obj : error LNK2001: unresolved external symbol _gzclose
Compress.obj : error LNK2001: unresolved external symbol _gzerror
Compress.obj : error LNK2001: unresolved external symbol _gzwrite
Compress.obj : error LNK2001: unresolved external symbol _gzopen
.\Debug/files.exe : fatal error LNK1120: 4 unresolved externals
Error executing link.exe.
The link settings include:
Object/library modules: zlib.lib
Project Options:
zlib.lib
In the file using the gzX() functions, it
#include "zlib/zlib.h"
What else needs to be done here to use these functions?
Thank You.
EDIT: Using Visual Studio 6.0 C++
EDIT2: It turned out the static library I was using had the gz() functions taken out of them. The header file still had them which was misleading.
I grabbed the one off here to get zlib to build in windows. If you did the same, you may have forgotten to #define ZLIB_WINAPI before including zlib.h
you also need to add zlib.lib to your project's libraries:
Project properties->Linker->Input->Additional Dependencies.
When the build stops, ctrl-click on the URL to see the more verbose form of the log and check the actual command line passed to the linker. That at least will tell you whether the option to link against zlib is being respected. You may get other useful diagnostic output. One possibility could be that the architecture is different (eg you're building x64 but the lib is x86)
It turned out the static library I was using had the gz() functions taken out of them. The header file still had them which was misleading.