I wrote a series of custom C PostgreSQL functions in Notepad++. I used the VS2015 x64 Native Tools command line utility to compile the code and linked it. No problems and worked perfectly.
But as much fun as coding in Notepad++ is, I decided to create a project in Visual Studio. After several hours of getting configurations correct, I can get the project to compile, but not link.
The specific errors are:
Error LNK2019 unresolved external symbol "double __cdecl
DatumGetFloat8(unsigned __int64)" (?DatumGetFloat8##YAN_K#Z)
referenced in function "unsigned __int64 __cdecl wrapf64(struct
FunctionCallInfoData *)"
(?wrapf64##YA_KPEAUFunctionCallInfoData###Z) ...
Error LNK2019 unresolved external symbol "unsigned __int64 __cdecl
Float8GetDatum(double)" (?Float8GetDatum##YA_KN#Z) referenced in
function "unsigned __int64 __cdecl wrapf64(struct FunctionCallInfoData
*)" (?wrapf64##YA_KPEAUFunctionCallInfoData###Z) ...
The symptom appears to be in fmgr.h (comments by me):
/* these macros hide the pass-by-reference-ness of the datatype: */
#define PG_GETARG_FLOAT4(n) DatumGetFloat4(PG_GETARG_DATUM(n)) // missing a definition
#define PG_GETARG_FLOAT8(n) DatumGetFloat8(PG_GETARG_DATUM(n)) // missing a definition
#define PG_GETARG_INT64(n) DatumGetInt64(PG_GETARG_DATUM(n))
Looking in postgres.h we see:
#ifdef USE_FLOAT8_BYVAL
extern float8 DatumGetFloat8(Datum X);
#else
#define DatumGetFloat8(X) (* ((float8 *) DatumGetPointer(X)))
#endif
There is no #define. Adding one doesn't resolve the issue.
By contrast:
#ifdef USE_FLOAT8_BYVAL
#define DatumGetInt64(X) ((int64) GET_8_BYTES(X))
#else
#define DatumGetInt64(X) (* ((int64 *) DatumGetPointer(X)))
#endif
This is the unedited source code of PostgreSQL and it worked from the command line utilities. What's the problem inside VS? Or, should I say, why did it work in the command line linker when the #define is missing?
Any suggestions?
One other question I have is my original code had abs(double ...) but inside VS I have to use fabs(double ...). Is this a C vs C++ point? I couldn't find a clear answer in MSDN.
For anyone else who might have similar issues, the answer is to ensure the source files are C, not C++.
Related
I have been updating a big working C++ Windows application in Visual Studio 2022 into several static libs.
The idea is to share part of the code to an external developer, and not share the complete C++ files of the project. Only part of the code would be shared, and the rest would be .lib's and .h's.
The structure of the entire solution is:
External LIB
Library 1 LIB - Referencing .h's from the External LIB
Application EXE - Using the above libs
When building the application EXE, the link fails with thousands of errors of missing symbols from the External LIB. "LNK2001 unresolved external symbol "__declspec(dllimport) public: bool __thiscall ..."
1>Common.lib(LocalizedString.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: bool __thiscall cocos2d::Value::isNull(void)const " (__imp_?isNull#Value#cocos2d##QBE_NXZ)
1> Hint on symbols that are defined and could potentially match:
1> "__declspec(dllimport) public: bool __thiscall cocos2d::Data::isNull(void)const " (__imp_?isNull#Data#cocos2d##QBE_NXZ)
The EXE is configured to include all the libs (configured in VS project settings: Additional Dependencies).
All the projects are being built with __cdecl (/Gd) and Multi-threaded Debug DLL (/MDd).
If I add to the EXE code some dummy declarations of symbols that are being referred into the "unresolved external symbol" error, Visual Studio adds those symbols and I can see the number of errors decreasing. But this is not a good solution...
It looks like somehow Visual Studios is adding all the symbols automatically.
I believe this whole issue may be related with the following. When building my libs I get the following "warning LNK4006: XXXX already defined in XXXXX.lib(xxhash.obj); second definition ignored".
I have tried different project settings, like "Link Library Dependencies: Yes". But nothing seems to fix it.
I'm stuck with this for two days... Can someone save me?
Found the problem. There was an hidden define in the external lib adding the dllimport to every external class.
#if defined(CC_STATIC)
#define CC_DLL
#else
#if defined(_USRDLL)
#define CC_DLL __declspec(dllexport)
#else /* use a DLL library */
#define CC_DLL __declspec(dllimport)
#endif
#endif
I have a Microsoft Visual 2010 project that runs fine in the Win-32 compilation setting. I am running on Windows 10. I am trying to use the x64 to build for 64-bit but that is when I encounter the LNK errors (examples below):
error LNK2028: unresolved token (0A00015D) "extern "C" unsigned char __cdecl
UcanDeinitCan(unsigned char)" (?UcanDeinitCan##$$J0YAEE#Z) referenced in function
"public: unsigned int __cdecl CAN::DeConfigDev(void)" (?DeConfigDev#CAN##$$FQEAAIXZ)
CAN.obj
error LNK2019: unresolved external symbol "extern "C" unsigned char __cdecl
UcanDeinitCan(unsigned char)" (?UcanDeinitCan##$$J0YAEE#Z) referenced in function
"public: unsigned int __cdecl CAN::DeConfigDev(void)" (?DeConfigDev#CAN##$$FQEAAIXZ)
CAN.obj
error LNK2001: unresolved external symbol __imp___glewGenBuffers Patient_GPU.obj
I've attempted to change the /clr function, as well as the calling convention (_cdecl ...) in an attempt to follow other solutions related to the LNK errors but neither has worked. Is there a different way to fix these errors, or get a better idea of what they actually mean? Any help would be greatly appreciated. Thank you so much!
You're probably linking UCAN static library from somewhere. You need to make sure that in 64bit configuration, you link to 64bit .lib file.
First thing to check is Additional dependencies config and check what libraries are linked into the project.
I'm really confused, i'm stuck with this problem, i hope you can help me :
I use : Windows 8.1, Visual Studio Express 2013 and SOCI 3.2.2
I have compiled both libsoci_mysql and libsoci_core and linked them into my project, but when i launch the compilation this error appear :
Error 1 error LNK2001: external symbol unresolved "struct soci::mysql_backend_factory const soci::mysql" (?mysql#soci##3Umysql_backend_factory#1#B) dbConnection.obj Server
I'm a little bit lost with Window, but i'm praticly sure libsoci_mysql.lib is found and (i have open the .lib with GNU emacs) contains the symbols.
Looks like it's a known problem with MSVC. The proposed workaround is to replace soci::mysql usage with *soci::factory_mysql().
In case someone else stumbles upon this I ran into a similar problem where odbc_option_driver_complete was undefined.
The issue was that this is defined in the header as an external and implemented in DLL. By default when building the DLL the code sets up a #define to eventually set __declspec(dllexport) for the external.
However, when you include the header in your code it does NOT by default set __declspec(dllimport) for the external! To trigger this you must #define SOCI_DLL in YOUR project to set this up.
Ideally your should set this in Project Properties -> C/C++ -> Preprocessor -> Preprocesor Definitions
I want to use the source code of the CvCaptureFromFile(..) function as I do not want to use OpenCV library functions in my project. So I went inside the function by pressing F10,F11 and I copied the things I needed and converted them into C code. Till now everything was ok.
But when I tried to run I am getting linking error inside the function icvIntFFMPEG(void)
the errors are as follows:
Error 1 error LNK2019: unresolved external symbol
"__declspec(dllimport) void * __stdcall GetProcAddress(struct
HINSTANCE__ *,char const *)"
(__imp_?GetProcAddress##YGPAXPAUHINSTANCE__##PBD#Z) referenced in
function "void __cdecl icvInitFFMPEG(void)" (?icvInitFFMPEG##YAXXZ)
Error 2 error LNK2019: unresolved external symbol "struct HINSTANCE__
* __stdcall LoadLibrary(char const *)" (?LoadLibrary##YGPAUHINSTANCE__##PBD#Z) referenced in function "void
__cdecl icvInitFFMPEG(void)" (?icvInitFFMPEG##YAXXZ)
I copied everything as it is in the source code. Any idea where I am going wrong? How do I solve this error?
UPDATE: IF I wrap the header file (where I was coping the source code) inside an extern "C" something like this-
extern "C" {
#include "defination.h"
}
Then the first error is gone, and the error with loadLibrary changes to
error LNK2019: unresolved external symbol __imp__LoadLibrary#4 referenced in function _icvInitFFMPEG
OpenCv uses ffmpeg - which is a really big project. And ffmpeg uses some other tools behind curtains. You may want to go using ffmpeg, but to take the source code from ffmpeg itself is foolish - you will spend years fiddling with that code - really.
So, decide on a video input library - be it OpenCV, ffmpeg, Direct3D or whatever, and use it.
Do not cling yourself on the idea that 'you cannot use external libraries' because you can't go without them. It takes years to develop such a library - I am pretty sure you do not want to go that way.
Well, it seems your get unresolved calls to LoadLibrary()/GetProcAddress() functions that are inside Kernel32.dll. What IDE/project type are you using? Kernel32.lib should be linked in by default unless /NODEFAULTLIB is specified somewhere, at least as far as I remember. You can try to add #pragma comment(lib, "kernel32.lib") to the file where you copied the code, but without more info about your setup it is hard to answer what is causing this.
I am getting the following linker error when trying to link an application to a "3rd-party library", where I myself build the 3rd-party library in question. Here is the error I get:
error LNK2001: unresolved external symbol "public: static class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >
const namesp::classname::VARIABLE" (?VARIABLE#classname#namesp##2V?$basic_string#DU?
$char_traits#D#std##V?$allocator#D#2##std##B) <path\to\mylib>.dll : fatal error LNK1120: 1 unresolved externals
The variable in question is defined in a class which is built as part of the 3rd party library. Here is the snippet of the class header as concerns the variable in question:
namespace namesp {
class MY_EXPORT classname {
public:
static const std::string VARIABLE;
};
}
while the corresponding snippet of the cpp is as follows:
#include <namesp/classname.hpp>
namespace namesp {
const std::string classname::VARIABLE = "VARIABLE";
}
The export symbol is defined in a separate header as follows:
#if defined(WINDOWS) && defined(SHARED)
#if(COND)
#define MY_EXPORT __declspec(dllexport)
#else
#define MY_EXPORT __declspec(dllimport)
#endif
#else
#define MY_EXPORT
#endif
Finally, I am using it in my application cpp as follows, say:
#include <namesp/classname.hpp>
namespace appnamesp {
appclass::somefunc() {
namesp::classname cn; //-Compiles
namesp::anotherclass ac; //-Compiles
ac.func(); //-Compiles
std::string s = namesp::classname::VARIABLE; //-Linker error
other stuff;
}
}
This results in the linker error on Windows 64 bit Vista, MS VS2008. What bothers
me is that
This error is not seen on linux, same application built with RHEL5 gcc4.1.2
Another class defined via same export symb is usable..
What am I doing wrong? Is this something to do with the static keyword, or is it the export symbol? My suspicion is the latter, but then I have another class that doesn't involve static variables that is defined similarly in my 3rd party library and accessed via the same export symbol which does not lead to linker errors, as indicated above.
This confuses me.
Shouldn't __declspec(dllimport) be __declspec(dllexport) ?
I figured out the answer to this.. yes, it is related to what OJ wrote. Basically I was missing a cmake definition that activated a condition that defined a symbol to __declspec(dllexport). Thanks anyway to #OJ for his pointer.