The function RtlInitUnicodeString() used to initialize the UNICODE_STRING structure cannot be used as a linker error stating that an unresolved external symbol RtlInitUnicodeString referenced in function ***func_name*** (LNK2019) is thrown during compilation.
I tried using the statement #pragma comment(lib, "NtosKrnl.lib") to solve the issue at hand (as I assumed that linking the library mentioned here would resolve it) but a linker error stating the message cannot open file 'ntoskrnl.lib' (LNK1104) is thrown.
Thanks in advance.
The function cannot be called directly as they belong to the internal API and their mere prototype header is exposed via the winternl.h header file (at least in this case). In order to use the functions that are part of the internal API, one can either use run-time dynamic linking to link the Ntdll.dll library as stated here or link the library file ntdll.lib, which is a provided as a part of the WDK.
Related
I am trying to use CImg library for some image processing task. Using VS 2012 on Windows 7 x64, I am building a project to create dll that I need for my application. I have included the only header file CImg.h from the library. But as soon as I initialize an CImg object, I get bunch of unresolved external symbol errors. One sample error is as follows:
layer.obj : error LNK2019: unresolved external symbol __imp_SetDIBitsToDevice referenced in function "public: struct cimg_library::CImgDisplay & __cdecl cimg_library::CImgDisplay::paint(void)" (?paint#CImgDisplay#cimg_library##QEAAAEAU12#XZ)
Can anyone explain to me what am I doing wrong and how to fix it? (I am a newbie when it comes to C++ terminologies.)
there is nothing other than the header file in the CImg library to link to.
You cannot link to a header file. If it is a header-only library, then you do not need to link anything. You include the header file and the functions it defines are compiled directly. That appears to be the case for CImg; the documentation says it is a self-contained template library that consists of only a single header file. So indeed, all you need to do is include it and you're off to the races.
The unresolved external symbol errors are coming from somewhere else. You have to read the error messages and look at the function names to see where.
A couple of hints:
The __imp_ prefix suggests that you're looking at a Windows API function.
If you didn't know that, you could always ignore the prefix and Google the readable part of the name, in this case, SetDIBitsToDevice. Chances are very good you'll turn up the documentation or at least something that points you in the right direction.
Indeed, in this case, you get right to Microsoft's SDK documentation for the SetDIBitsToDevice function. It's a Windows API function alright, and Microsoft's documentation always tells you what library you need to link to in order to consume it. Look at the bottom of the page:
Header: Wingdi.h (include Windows.h)
Library: Gdi32.lib
DLL: Gdi32.dll
The CImg library header file has obviously already included the Windows.h header file, or you'd have gotten a compile-time error. You're getting a linker error, which means that you have not told the linker to link in the Gdi32.lib library. This is what will allow you to call GDI functions. It is a stub that facilitates calling functions exported from Gdi32.dll.
In general, when building a Windows application, you will want to link with, at minimum, kernel32.lib, user32.lib, and gdi32.lib.
This question contains more information on dealing with undefined symbol errors, and also how to configure your linker. In Visual Studio, go to Project Properties → C/C++ → Linker → Input → Additional Dependencies. Or add #pragma comment(lib, "gdi32.lib") to a source file (your precompiled header is a good place, usually named StdAfx.h).
This function is part of the win32 API, specifically in GDI. You need to change your project settings to link with Gdi32.lib
https://msdn.microsoft.com/en-us/library/windows/desktop/dd162974(v=vs.85).aspx
I maintain an old project and encountered some linker errors.
The error message is:
error LNK2019: unresolved external symbol __imp__bsearch referenced in function "bool __cdecl is_sync_host
As far as I know, the bsearch function is included in the header file "cstdlib" or "stdlib.h", but even if I include the header, I can't find "bsearch".
I suspect this is due to the fact that this old project ignores some lib because of symbol conflicts (I also don't know why they prefer to omit the lib instead of renaming the functions)
The ignored libs : msvcrt.lib;msvcrtd.lib;libcmt.lib;libc.lib
I try to add those ignored libs back, but then I encounter a lot of "symbol redefinition" problems and I don't think that renaming those functions is an applicable solution.
I found a work around (replace the bsearch to std::binary_search), but I want to know why and how to solve this problem properly (how comes the compiler can't find the bsearch?). Thanks.
error LNK2019:
This is a linker error. Your code compiled just fine (.c > .o), it is the linking that gives you problems (.o > .exe).
The ignored libs : "msvcrt.lib;msvcrtd.lib;libcmt.lib;libc.lib"
This means the code is ignoring the C standard library, so no wonder it doesn't find the standard bsearch() function...
The question is, why? There is simply no reason (that I could think of) for well-written code to explicitly ignore the standard library.
I try to add those ignored libs back, but then I meet a lot of "symbol redefinition" problems...
Which brings me to the conclusion that your code is not "well-written", at which point it is very difficult to give advice without seeing the code, or telling you to "ditch it, it's crap". ;-)
I don't think that rename those functions is an applicable solution.
If you have functions in your project that are named like standard library functions, unless your project is a standard library, they are misnamed and should be renamed.
But at this point, I would really like to see the code in question to figure out what the original programmer might have had in mind...
Getting many versions of the following linker error in XE5.
[ilink32 Error] Error: Unresolved external '__stdcall System::UnicodeString::~UnicodeString()' referenced from <Location>
From everything I've read so far, this seems like I have something wrong with my include structure in the project settings and have no access to where all the string methods are actually defined, but for the life of me, I cannot figure out where these are supposed to be.
This problem has nothing to do with includes. Include problems only affect the compiler. Your project is using the UnicodeString class, so the compiler generates references to UnicodeString's methods based on how they are declared in ustring.h, and that keeps the compiler happy.
You are getting a linker error instead, because it cannot resolve the references that the compiler generated. That means your project is missing a required reference to Embarcadero's RTL library that implements the actual UnicodeString method bodies. That likely suggests your project was created/imported incorrectly to begin with, or has become corrupted. You may have to recreate the project from scratch so the default library references are used, and re-add your existing code files to that new project.
I have a file foo.h that has various declarations for functions. All of these functions are implemented in a file foo.dll. However, when I include the .h file and try to use any of the functions, I get the error:
bar.obj : error LNK2019: unresolved external symbol SomeFunction
so obviously the function implementations aren't being found.
What do I have to do to help the compiler find the definitions in the DLL and associate them with the .h file?
I've seen some stuff about __declspec(dllexport) and __declspec(dllimport) but I still can't figure out how to use them.
You should have received at least three files from the DLL owner. The DLL which you'll need at runtime, the .h file with the declarations of the exported functions, you already have that. And a .lib file, the import library for the DLL. Which the linker requires so it knows how to add the functions to the program's import table.
You are missing the step where you told the linker that it needs to link the .lib file. It needs to be added to the linker's Input + Additional Dependencies setting of your project. Or most easily done by writing the linker instruction in your source code:
#include "foo.h"
#pragma comment(lib, "foo.lib")
Which works for MSVC, not otherwise portable but linking never is. Copy the .lib file to your project directory or specify the full path.
I just had a similar problem. The solution turned out to be that the DLL was 64 bit, and the simple app using it was 32. I had forgotten to change it to x64 in the Configuration Manager.
You need to specify in front of function definitions __declspec(dllexport) keyword at the time of building the dll
You need to import or load the .dll file into process memory.
You need to acquire the address of function you want to use from that dll.
Some useful links to get started:: MSDN Documentation, SO, Random
I'm trying to statically link to libcrypto.a (from the openssl library) after building it from source with a new toolchain. However whenever I try to use any of the functions from that library, I keep receiving "undefined reference" errors. I've made sure the right header file was included. I've also double checked the symbol table of libcrypto.a and made sure these functions are indeed defined.
Is there anything else I can do to debug this error- like getting more info out of the linker or examining libcrypto.a itself, to find out why the linker is spitting out "undefined reference" error when the indicted symbols shows up in the symbol table?
Undefined reference/symbol is a linker error indicating that the linker can't find the specified symbol in any of the object modules being linked. This indicates one or more of the following:
The specified class/method/function/variable/whatever is not defined anywhere in the project.
The symbol is inaccessible, probably due to an access specifier (in C++, doesn't apply to ANSI C)
The reference is incorrect. This can be due to a spelling error or similar problem. (unlikely)
You've neglected to include the required library in your build script when calling the linker.
I see your post is tagged c++. OpenSSL is written in C.
Did you remember to do
extern "C" {
#include <various SSL files>
}
?
grep the symbol out of libcrypto using nm
so you can see if its there - probably not (duh)
ssl has 2 libs , maybe you are using the wrong one
what exectly is the missing symbol