EDIT:
I've fixed the problem by setting my Runtime Library to inherit from project default.
I was using Multi-treaded DLL(/MT) because a SDL-2 tutorial I used did that.
Can someone explain why this broke the string's of c++?
Whenever I try to use a string my compiler gives me the following errors:
LNK2019 unresolved external symbol __imp___invalid_parameter referenced in function "void * __cdecl std::_Allocate(unsigned int,unsigned int,bool)"
LNK2019 unresolved external symbol __imp___CrtDbgReportW referenced in function "void * __cdecl std::_Allocate(unsigned int,unsigned int,bool)"
I've stripped all my code to the bare minimum and it is as followed:
#include <string>
int main(int argc, char *argv[]) {
std::string resPath;
return 0;
}
I have no idea where to look. Does anyone have an idea?
I'm using MSVS Community 2015.
I just had the same problem with VS2017. It turned out that I had my runtime library settings wrong. I had accidently set it to Multi-threaded DLL (/MD) for the debug configuration. It should have been Multi-threaded Debug DLL (/MDd) or Multi-threaded Debug (/MTd).
Related
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.
Here is my main loop:
#include <string>
#include <stdio.h>
#include <iostream>
#include <sqlite3.h>
using namespace std;
int main()
{
sqlite3 *database;
sqlite3_open("db.sql", &database);
return 0;
}
When I compile it, it throws a linking error. Errors are as follow:
1>Students.obj : error LNK2028: unresolved token (0A000451) "extern "C" int __cdecl sqlite3_open(char const *,struct sqlite3 * *)" (?sqlite3_open##$$J0YAHPBDPAPAUsqlite3###Z) referenced in function "int __cdecl main(void)" (?main##$$HYAHXZ)
1>Students.obj : error LNK2019: unresolved external symbol "extern "C" int __cdecl sqlite3_open(char const *,struct sqlite3 * *)" (?sqlite3_open##$$J0YAHPBDPAPAUsqlite3###Z) referenced in function "int __cdecl main(void)" (?main##$$HYAHXZ)
1
How can I solve it? I should say that in Microsoft Visual Studio 2013, I have disabled pre-compiled headers, added a directory for my SQL.sql in Linker->additional directories, also added my headers and cpp files to aditional # include directories.
You will need to include the source file(s) that came with sqlite3 in your project. (Or, you could create a library that you would include with your project, but that's a slightly more complex answer.)
Anyway, yea, you probably have a file called "sqlite.c" -- just include that with your project so that it compiles as well. You may still have some other errors/warnings to resolve; however, I think that will take care of the unresolved externals.
If you have .lib or .dll files instead of actual source, then you'll just need to include those in your project similarly.
I am trying to solve the following issue: I've got a library which uses C++Amp. The library compiles without any warnings and the unit-tests indicate that everything is working. I have a QT-based project which is a GUI for this library and here the problems begin. Everytime I am compiling the GUI, in the linking stage a get the following errors:
widgets.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) private: unsigned short const * __cdecl Concurrency::accelerator::_Get_device_path(void)const " (_imp?_Get_device_path#accelerator#Concurrency##AEBAPEBGXZ) referenced in function "void __cdecl `dynamic initializer for 'public: static class std::_Future_error_category std::_Future_error_object::_Future_object''(void)" (??__E?_Future_object#?$_Future_error_object#H#std##2V_Future_error_category#2#A##YAXXZ)
The library is linked to lib file, not dll.
Same story goes for other object files in the project. Did anyone have a similar problem at the linking stage when using C++Amp. I am sure that it is a very simple problem to solve but at the moment I have no idea how I could do it. Thanks in advance.
Update: the same happens when I am trying to include in the QT project in MSVC++.
__imp_?_Get_device_path#accelerator#Concurrency##AEBAPEBGXZ
Running the undname.exe utility on that string to unmangle the name, I get:
declspec(dllimport) private:
unsigned short const * __ptr64
__cdecl Concurrency::accelerator::_Get_device_path(void)const __ptr64
So it is 64-bit code. Looking in vc/lib/amd64/vcamp.lib for a closest match, I find:
?_Get_device_path#accelerator#Concurrency##AEBAPEB_WXZ
Which demangles with undname.exe to:
private:
wchar_t const * __ptr64
__cdecl Concurrency::accelerator::_Get_device_path(void)const __ptr64
Note the discrepancy. Your function got compiled to return unsigned short*, the library function returns wchar_t*. You have a compiler setting wrong. Project + Properties, C/C++, Language, Treat WChar_t As Built in Type must be set to the default, "Yes".
When I am using Qt (v4.7.4) and Boost (tried v1.47 and v1.48) together in my c++ project, I get a linker error caused by a class that includes <boost\filesystem.hpp>. I just set up Qt and before the code was working without any problems.
This is error message:
...obj : error LNK2001: unresolved external symbol "private: static class std::codecvt const * & __cdecl boost::filesystem3::path::wchar_t_codecvt_facet(void)" (?wchar_t_codecvt_facet#path#filesystem3#boost##CAAAPBV?$codecvt#GDH#std##XZ)
...obj : error LNK2001: unresolved external symbol "void __cdecl boost::filesystem3::path_traits::convert(char const *,char const *,class std::basic_string,class std::allocator > &,class std::codecvt const &)" (?convert#path_traits#filesystem3#boost##YAXPBD0AAV?$basic_string#GU?$char_traits#G#std##V?$allocator#G#2##std##ABV?$codecvt#GDH#5##Z)
...obj : error LNK2001: unresolved external symbol "void __cdecl boost::filesystem3::path_traits::dispatch(class boost::filesystem3::directory_entry const &,class std::basic_string,class std::allocator > &,class std::codecvt const &)" (?dispatch#path_traits#filesystem3#boost##YAXABVdirectory_entry#23#AAV?$basic_string#GU?$char_traits#G#std##V?$allocator#G#2##std##ABV?$codecvt#GDH#6##Z)
...obj : error LNK2001: unresolved external symbol "void __cdecl boost::filesystem3::path_traits::convert(unsigned short const *,unsigned short const *,class std::basic_string,class std::allocator > &,class std::codecvt const &)" (?convert#path_traits#filesystem3#boost##YAXPBG0AAV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##ABV?$codecvt#GDH#5##Z)
...exe : fatal error LNK1120: 4 unresolved externals
EDIT:
Here I found someone having this problem coming to this conclusion:
this really is a Qt issue. Using wchar_t as a native type you have to
recompile Qt using the same compiler switch. There even is a bug in the
tracker: https://bugreports.qt.io/browse/QTBUG-9617
In general, you will have to be very careful and do not mix wchar_t
compiler settings in your projects as they will become incompatible.
So I recompiled Qt setting /Zc:wchar_t, but it didn't show any effect. I still get the same error.
I think you are on the right track, but it sounds like your -Zc:wchar_t didn't "stick." We had to do the same thing to make Qt happy with Google Breakpad and the ICU library. We changed the /Zc:wchar_t setting in (QT_SOURCE)\mkspecs\win32-msvc2008\qmake.conf and compiled Qt from source, and after that everything works.
When you build your project that uses Qt and Boost, you should see this option in the compiler output. Something like:
cl -c -nologo -Zm200 -Zc:wchar_t ... (etc.)
If you've already build Qt without this option, you may have to do a make confclean first to ensure everything really gets rebuilt with the new settings.
It sounds like -Zc:wchar_t will be the default in Qt 5.
Using boost-1.49, Qt 4.4 and VS2005 had the same problem. Going to project properties, then setting "Configuration Properties -> C/C++ -> Language -> Treat wchar_t as Built-in Type" to "Yes" fixed the problem.
Qt probably changed the tipology of your program with regards the configuration of the runtime: consequently, the boost library you use (filesystem), that come in many configuration accessed by naming convention - connot be found.
For instance, multithread runtimes require mt somewhere in library name (I hope I remember well, but anyway see the docs where details are fully documented). This naming is fairly transparent to the programmer, due to pragmas that boost programmers appropriately used to ease the library usage under different compilers.
You should miss the non-wchar filesystem.lib. When I used Windows, I used boost Jam to interface with Visual C++ (may be that goes back to the past millenium!). I hope it's still usable.
HI I'm an internship student and my job is porting a program from linux c to visual c.
I've to use Berkeley DB and Visual C++.
after trying for a while, i get the linking error
berkeleyDB.obj : error LNK2019: unresolved external symbol "int __cdecl database_select_end(unsigned int,unsigned int,struct chunk * const,int)" (?database_select_end##YAHIIQAUchunk##H#Z) referenced in function "void __cdecl op_ds_bulk(unsigned int,unsigned int *,int)" (?op_ds_bulk##YAXIPAIH#Z)
berkeleyDB.obj : error LNK2019: unresolved external symbol "void __cdecl database_sync(void)" (?database_sync##YAXXZ) referenced in function "void __cdecl op_ds_bulk(unsigned int,unsigned int *,int)" (?op_ds_bulk##YAXIPAIH#Z)
berkeleyDB.obj : error LNK2019: unresolved external symbol "void __cdecl database_insert_bluk(struct chunk *,int)" (?database_insert_bluk##YAXPAUchunk##H#Z) referenced in function "void __cdecl op_ds_bulk(unsigned int,unsigned int *,int)" (?op_ds_bulk##YAXIPAIH#Z)
berkeleyDB.obj : error LNK2019: unresolved external symbol "int __cdecl database_open(int,char *)" (?database_open##YAHHPAD#Z) referenced in function _main
no idea what are those,
pls help me
They're C++-mangled (or 'decorated') function names. C++ allows function overloading - multiple functions with the same name but with different parameter signatures - and so it needs to encode the parameters etc. into the function name to differentiate the multiple overloads at link time. Most likely your DB library was built as C and won't have decorated names.
Try wrapping your db.h include in an extern "C"
extern "C"
{
#include <db/db.h>
}
to tell the compiler to treat the API as C functions, not C++.
(It looks like you've got a typo in there too: database_insert_bluk not _bulk.)
Alternatively, it looks like Berkeley DB ship a C++ interface #include <db/db_cxx.h> you could use instead, although if you're porting code it may be easier to stick to the C interface. The difference is probably that the Linux code you're porting was compiled as C whereas here you're compiling it as C++.
From the other comment you've posted: if your problem is that you're actually not linking in Berkeley DB at all then you'll need to go into project settings (right-click on the project name), the C++ link tab, and then add the .lib file to the list of libraries to link into your project. You may need to specify the path to find this too, and you should do this for both debug and release modes (the drop down at the top of the settings).