I've got an NIUSB8452 DAQ, with which the vendor thoughtfully provided ni845x.lib and ni845x.h so I could use C instead of LabView to do my data reading. However, I'm having some problems with getting the lib working in VisualStudio 2015. The first point of alarm is probably that their documentation says it is compatible with VS6, but I've seen other people on here successfully use libraries for VS6 on VS15, so, I hope I can also be so beautiful.
The problem that I am having right now is that on a build, I'm getting linker errors that read something like
unresolved external symbol #ni845xStatusToString#12 referenced in function (function name follows)
While googling around, I found this question which mentioned dumpbin /exports. To check that I wasn't running into a 32/64 bit error like the poster described (since I wasn't really sure how to diagnose this, it seemed as good a place to start as any), I ran dumpbin /exports on the external lib. I got a pile of public symbols, including
FF06 __imp__ni845xStatusToString#12
FF06 _ni845xStatusToString#12
I'm definitely not seeing #ni845xStatusToString#12, which is what VisualStudio is complaining about being unresolved.
What's the difference between #ni845xStatusToString#12 and _ni845xStatusToString12? What does the presence of the latter and the absence of the former indicate that I am doing wrong with this import?
Notes
The lib and header have been included in the file as described in this question, with the exception that I gave a full path to the lib for #4, which I think implies you only need the filename.
I'm using extern "C" { #include ni845x.h } in my cpp file, although ni845x.h does have the #ifdef __cplusplus boilerplate in there.
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'm making a C++ program and I want to use FFmpeg pre-built for x64, which is a C-compiled library.
I'm using this code in order to include its header:
extern "C" {
#include "libavcodec/avcodec.h"
#include "libavformat/avformat.h"
#pragma comment (lib,"G:/Documents/ffmpeg/lib/avcodec.lib")
#pragma comment (lib,"G:/Documents/ffmpeg/lib/avformat.lib")
}
I'm then calling the symbols like I would do for a normal function, for example with av_interleaved_write_frame(out->formatContext, &packet);
However, when I try to compile it with Visual Studio 2015's built-in C++ compiler, I get a lot of error like
Error LNK2019 unresolved external symbol _av_write_trailer referenced in function "void __cdecl closeArenaVideo(struct VideoOutput *)" (?closeArenaVideo##YAXPAUVideoOutput###Z) Sparta2 c:\Users\Théo\documents\visual studio 2015\Projects\Sparta2\Sparta2\video.obj
for basically any of the symbols I'm refering to.
I tried to import everything in Visual Studio, to compile with command-line, to manually put FFmpeg's libraries in the default libraries path, without success.
Thank you in advance!
A typical problem which is hard to understand from quoted linker errors is the problem of referencing wrong .lib files, esp Win32 platform libraries in x64 build and vice versa. The names might be correct, but the set is wrong and then linker takes the #pragma references but ignores the content.
You should make sure that your build platform matches the bitness of referenced library files. This answer has minimalistic project which does build well and you can compare code/references to what you use, and it also mentions bitness problem as well in the very bottom and comments to the answer.
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...
I am receiving a lot of strange LNK2001 and LNK2019 errors when attempting to compile and link against a somewhat large static library (developed in-house). Here are the facts:
There are several static libs (most built in-house) all compiled into one large wrapper static lib for public consumption ("Pimpl" idiom). Essentially, we have libs A, B, and C all compiled into an internal/private lib called D. Then, we have an external/public lib that wraps around D called E.
The final product is not an executable, but a plug-in for Adobe Illustrator. Plug-ins are essentially just a DLL with a couple special resources and a special entry point (PluginMain() function). Compiling and linking works just great until I use the /INCLUDE option to specify that PluginMain should always be exported.
Creating a plug-in and linking against lib D works fine (no errors whatsoever). Creating a plug-in and linking against lib E gives over 100 unresolved symbol errors (symbols that should be present in E).
When I run DUMPBIN on the E.lib file, it appears to have all the symbols that the linker is complaining about when trying to create a plug-in. However, I'm not entirely certain I understand all the output syntax from DUMPBIN...
The libs are all cross-platform and compile and link just fine with GCC/LLVM on Mac.
Most of the functions that the linker complains about are either plain functions or static member functions. Most of those look suspiciously like functions that the compiler might try to inline. I have tried disabling optimization and/or automatic inlining, but the same link errors are still present.
Can anyone point me in the direction of some compile and/or link settings that might resolve the issue? Settings that are commonly misconfigured in situations like this?
Perhaps there is a setting I missed that is causing the linker not to export these symbols when linking E? Perhaps there is a setting that forces the linker to export ALL symbols when linking E that I can try? Maybe a utility exists to help me inspect the lib symbols myself for a clue?
I feel like I've tried everything, but it never hurts to ask. Thanks all.
EDIT 1: snowdude requested an actual link error:
E.lib(PathArt.cpp.obj) : error LNK2001: unresolved external symbol "private: __thiscall E::PathSegPoint::PathSegPoint(struct D::PathSegPoint const &)" (??0PathSegPoint#E##AAE#ABU0D###Z)
I should add that E::PathSegPoint::PathSegPoint(const D::PathSegPoint&) is a private constructor for constructing an external/public consumable E::PathSegPoint object from an internal/private D::PathSegPoint object. Again, this is the "Pimpl" idiom. Some classes/functions are friends of E::PathSegPoint to enable this sort of construction.
I thought I'd post an answer in case anyone shows up to this page in the future.
For several reasons a few years ago, we started compiling these libraries with the Intel C++ compiler inside Visual Studio. Some of these reasons have changed, and we needed to switch back to the MSVC compiler. Upon switching to the MSVC compiler, these linker errors disappeared!
I don't know why or how the Intel C++ compiler developed these link problems, but it's entirely possible that this is a bug.
I am trying to get the ARPACK library to run on VS2010.
I would like to use the C++ wrappers
provided by ARPACK++ (some background - i need to get eigenvalues and eigenvectors of huge matrices). There is a very good tutorial on the subject here.
Following the
tutorial i've managed to compile the fortran code using g77 on mingw, i successfully generated
the dll and lib as described. The problem arises when trying to link my visual studio project to the library.
The way i'm trying to link is as follows:
I've made a simple VS2010 C++ console app
i've added the the folder containing ARPACK++ libraries to my "additional include folders"
i've added the lib file to "Additional dependencies"
i've added the directory containg the lib file to my "Additional library directories"
Despite these settings when i try to compile this short test code:
#include "stdafx.h"
#include "arrsnsym.h"
int _tmain(int argc, _TCHAR* argv[])
{
ARrcNonSymStdEig<float> prob(100, 4L);
printf("Bok!");
return 0;
}
I get an error saying:
>arpackcpp.obj : error LNK2001: unresolved external symbol scopy_
1>arpackcpp.obj : error LNK2001: unresolved external symbol snaupd_
1>arpackcpp.obj : error LNK2001: unresolved external symbol sneupd_
I do not understand why the linker can't find the mentioned methods. Inspecting
the .def file generated by the dllwrap utility does indeed mention all these functions
so i am fairly sure they should be available. Still, i feel i'm missing something obvious.
UPDATE (got it working!):
It turns out that i was trying to link a 64 bit program to a 32 bit library, when switching
to x86 in the Configuration settings AND including the generated def file in Configuration Properties -> Linker -> Input -> Additional definition file, it worked for 32bit (however i needed 64). The final solution that worked for me was to cross compile it for Win64 using MinGW and gfortran on linux. That worked surprisingly well and produced a dll to which i could link from a 64bit C++ app in VS. I think i should now go write a tutorial on how to do this :)
My guess is that this is a name-mangling scheme issue. In fortran, it is not well defined what name the symbols will have in the object file's symbol table. For example, a routine named foo could end up in the symbol table as foo,FOO,foo_,foo__ and so on. These days, I don't know of too many compilers that use double underscores (with g77 being the exception). I'm assuming the ARPACK++ wrappers are assuming a single underscore. The solution here is to tell the compiler to use single underscores in the symbol names (with g77, that means using -fno-second-underscore). Note that gfortran is a newer (still supported) open-source fortran compiler which does single underscoring by default. You might want to try to build your code using that compiler as well. (It might produce more optimized output than g77.)