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.
Related
A C++ project can be compiled by VS6 without errors&warnings.
With VS 2013 Prof., linker problems are occuring. They are providing a pattern namely std::basic_string.
The code was written in 2007 but not by me.
Referenced by a constructor:
vrun.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: char const * __thiscall
std::basic_string,class
std::allocator >::c_str(void)const " (__imp_?c_str#?$basic_s
tring#DU?$char_traits#D#std##V?$allocator#D#2##std##QBEPBDXZ)
referenced in fun ction "public: __thiscall VTrs::VTrs(class
VMessageContext &)" (?? 0VDMTrs##QAE#AAVVDMMessageHandlerContext###Z)
In vrun.cpp:
VTrs::VTrs(VMessageContext& handler_):
Inherited(RXS::rName().c_str()),
_handler(handler_)
{
}
(c_str -> const char* c_str() const; --- C98 style --- C11 was not applied in the project till yet)
In vrun.h:
VTrs(VMessageContext&);
Referenced by an operator:
vrun.obj : error LNK2019: unresolved external symbol "__declspec(dllimport)
public: int __thiscall std::basic_string<char,struct std::char_traits<char>,cl
ass std::allocator<char> >::compare(char const *)const " (__imp_?compare#?$basi
c_string#DU?$char_traits#D#std##V?$allocator#D#2##std##QBEHPBD#Z) referenced in
function "bool __cdecl std::operator==<char,struct std::char_traits<char>,clas
s std::allocator<char> >(class std::basic_string<char,struct std::char_traits<c
har>,class std::allocator<char> > const &,char const *)" (??$?8DU?$char_traits#
D#std##V?$allocator#D#1##std##YA_NABV?$basic_string#DU?$char_traits#D#std##V?$a
llocator#D#2##0#PBD#Z)
Refers -as far as interpreted- to a standard operator. (No operator overloading done for == which refers to a string)
By the way, the code itself does not contain "std::basic_string".
The according msdn article was read but this issue was not resolved till yet.
'Usual' issues such as the "C" modifier modifications are already considered for another code.
Any hint how to cope with that?
EDIT: When opening the project the first time with Visual Studio 2013, a kind of conversion dialog was displayed. I agreed but it affected the VC++ Directories. It was visible when comparing the project file with ClearCase to the previous verison. UndoCheckout (via ClearCase) applied the old state. Now it works.
Your linker needs to get the newer MSVC std library from the relevant lib file and it should pick this up when you migrate the project. Take a look at Project Properties->Configuration Properties->Linker->Input and make sure "Ignore All Default Libraries" is set to No
When opening the project the first time with Visual Studio 2013, a kind of conversion dialog was displayed. I agreed but it affected the VC++ Directories. It was visible when comparing the project file with ClearCase to the previous version. UndoCheckout (via ClearCase) applied the old state. Now it works.
I have two C++ projects which each form a library to be referenced by a third project all as part of a Visual Studio solution.
The two libraries were written by someone else who also provided his own VS solution which included a project which acts as a demo for some of the library functions. I have successfully gotten these to compile and run. I am trying to develop a Windows application using Windows Forms which will make use of the libraries. Upon including the two necessary headers,
#include "corelib.h"
#include "corbit.h"
and trying to build the code, I receive 2 link errors:
SatTrack_v0.1.obj : error LNK2028: unresolved token (0A000010) "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __clrcall Zeptomoby::OrbitTools::cGeo::ToString(void)const " (?ToString#cGeo#OrbitTools#Zeptomoby##$$FUBM?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##XZ) referenced in function "void __clrcall `dynamic initializer for 'const Zeptomoby::OrbitTools::cGeo::`vftable'''(void)" (???__E??_7cGeo#OrbitTools#Zeptomoby##6B###YMXXZ#?A0xc222cabd##$$FYMXXZ)
SatTrack_v0.1.obj : error LNK2019: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __clrcall Zeptomoby::OrbitTools::cGeo::ToString(void)const " (?ToString#cGeo#OrbitTools#Zeptomoby##$$FUBM?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##XZ) referenced in function "void __clrcall `dynamic initializerfor 'const Zeptomoby::OrbitTools::cGeo::`vftable'''(void)" (???__E??_7cGeo#OrbitTools#Zeptomoby##6B###YMXXZ#?A0xc222cabd##$$FYMXXZ)
C:\Users\Satellite Tracking\Software\SatTrack_v0.1\Win32\(Configuration)\SatTrack_v0.1.exe : fatal error LNK1120: 2 unresolved externals
I've read through What is an undefined reference/unresolved external symbol error and how do I fix it? and I thought I linked the necessary libraries. I've gone to the project Properties | Framework and References and added the libraries. I've also added the Additional Include Directories under Properties | Configuration Properties | C/C++ | General. Also, under Linker | General I've included the proper location in Additional Library Directories and I think I have the proper Additional Dependencies under Linker | Input. In general, I've gone through many of the project properties and tried to match them to the property settings of the working demo project, but the linker problem remains.
Am I simply still missing a link somewhere or is the problem more complicated than that? Because I do have the the demo solution compiling, is there a better way to take the link settings than manually going through all of them and trying to match those which are appropriate? I've been stuck on this problem for a couple days and can't figure out what I'm missing. Where should I go from here?
I'm using FTGL library in my Microsoft Visual Studio 2012, C++ project. I finally managed to properly link it to my project as I can properly render a font by using:
FTGLPixmapFont font("C:/Windows/Fonts/Arial.ttf");
font.Render("Hello world");
Everything seems to be ok until I try to create an object by using new operator:
FTGLPixmapFont* font = new FTGLPixmapFont("C:/Windows/Fonts/Arial.ttf"); // This causes error
font->Render("Hello world");
The code above produces this error:
AppLayer.obj : error LNK2001: unresolved external symbol "public: virtual float __thiscall FTFont::Advance(unsigned short const *,int,class FTPoint)" (?Advance#FTFont##UAEMPBGHVFTPoint###Z)
1>AppLayer.obj : error LNK2001: unresolved external symbol "public: virtual class FTBBox __thiscall FTFont::BBox(unsigned short const *,int,class FTPoint,class FTPoint)" (?BBox#FTFont##UAE?AVFTBBox##PBGHVFTPoint##1#Z)
1>AppLayer.obj : error LNK2001: unresolved external symbol "public: virtual class FTPoint __thiscall FTFont::Render(unsigned short const *,int,class FTPoint,class FTPoint,int)" (?Render#FTFont##UAE?AVFTPoint##PBGHV2#1H#Z)
I have completely no idea what can be reason for this. I'd really appreciate any answers.
Thanks!
It looks like you forgot to link a library, or to include a file in the build.
This class inherits the class FTFont. Check that you correctly linked the library including this definition.
In visual, you can just link the list by adding the .lib file to the project like if it is a cpp.
If you link another project from the visual solution, check in the properties of your project if the dependance to the other project is set correctly.
best
Those specific linker errors happen if the "Treat WChar_T As Built in Type" property (found in C/C++ / Language in the property pages) is set to 'Yes' for the complication of the FTGL library and 'No' for the compilation of your application using the library.
The compiler preparing functions with "WChar_t const*" as the argument type in the FTGL library, but your program will be looking for "unsigned short *const", and so won't find any function with that signature.
To fix, change the property "Treat WChar_T As Built in Type" in your project so that it matches the setting in the FTGL library; clean and recompile and it should work.
I have one C++ project with settings of Unicode as character set and /clr option for common language run time support. I am calling some function of MFC dll (with setting of MultiByte character set) and I am getting some liking error on those functions which are using wchar_t. Same dll is working file for those unicode c++ projects where /clr option is not set (i.e. no common language run time support). I have done the google and tried some thing like:--
Replace Cstring with std:string but both are giving same error.
Example for std: string:--
error LNK2001: unresolved external symbol "public: __thiscall
CEventLog::CEventLog(wchar_t const *)" (??0CEventLog##QAE#PB_W#Z)
for Cstring:--
error LNK2019: unresolved external symbol "public: bool __thiscall
CIITAdoField::GetValue(class ATL::CStringT > > &)"
(?GetValue#CIITAdoField##QAE_NAAV?$CStringT#_WV?$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL###Z)
referenced in function "public: bool __thiscall
Iit::DataFeedSvr::SpeedCache::CacheLoader > >,class
Iit::DataFeedSvr::SpeedCache::HolidayScheduleInfo,struct
Iit::DataFeedSvr::SpeedCache::HolidayScheduleSpeedCacheParam>
::Reload(class Iit::DataFeedSvr::SpeedCache::DoubleKeyCacheInstance > >,class
Iit::DataFeedSvr::SpeedCache::HolidayScheduleInfo,struct
Iit::DataFeedSvr::SpeedCache::HolidayScheduleSpeedCacheParam> &,class
CIITAdoRecordset &,enum
Iit::DataFeedSvr::SpeedCache::ERefreshType,class
Iit::DataFeedSvr::SpeedCache::CacheObserver const *)"
(?Reload#?$CacheLoader#V?$DoubleKeyCacheInstance#JV?$CStringT#_WV?$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL##VHolidayScheduleInfo#SpeedCache#DataFeedSvr#Iit##UHolidayScheduleSpeedCacheParam#456##SpeedCache#DataFeedSvr#Iit###SpeedCache#DataFeedSvr#Iit##QAE_NAAV?$DoubleKeyCacheInstance#JV?$CStringT#_WV?$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL##VHolidayScheduleInfo#SpeedCache#DataFeedSvr#Iit##UHolidayScheduleSpeedCacheParam#456##234#AAVCIITAdoRecordset##W4ERefreshType#234#PBVCacheObserver#234##Z)
I have checked the setting like "Treat Wchar_t as Built in type" and it is file.
I have tried to explicitly export function and class using __declspec(dllexport) but no luck.
I can not change my project from unicode to multibyte or can not change the setting of /clr option as it starts giving other error.
Please suggest the solution. Thanks in advance.
Do a 'dumpbin' on the external DLL to see what's exported. If your CEventLog::CEventLog is not exporting a char based constructor you won't be able to import it, simple as that.
It doesn't look from your example that the /clr switch is causing the problem. Try creating a brand new Unicode project (without the CLR) just to check you really can link to the external DLL.
I have a third party libs. (msvc10) a MT/MD (Static cfgs's) and dynamic DLL cfg.
I have qt + msvc10 express + win sdk.7
Ok , I use the existing examples offered, (using the libs) I can't compile ..... I have 4 unresolved external errors of the same lib.
(But I have zero errors for the others)
I have not support for these lib...... (but they are legal, I am a member without rights)
Which are the steps to investigate a possible fix? Where I have to look ?
Thanks.
Edit 1:
The errors was:
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegEnumValueW#32 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegCloseKey#4 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegQueryValueExW#24 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol __imp__RegOpenKeyExW#20 referenced in function "public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const &,class OdString &)" (?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
..\exe\OdaQtApp.exe : fatal error LNK1120: 13 unresolved externals
During this post I have received a solution: I have to link with Advapi32.lib...
My question is : how can I know this ?
I have tried the dependencyywalker, but it cant use the .lib's....
During this post I have received a solution: I have to link with Advapi32.lib... My question is : how can I know this?
When you get an "unresolved external" error from the linker, that means that it was looking for a match for a function or variable name that some object file needs and the linker was unable to find that name defined in one of the object files or libraries.
Start by looking at the first of these errors (I've reformatted it a bit to make it slightly more readable - I encourage yo to do the same next time you come across one of these):
TD_ExamplesCommon.lib(ExHostAppServices.obj) : error LNK2019: unresolved external symbol
__imp__RegEnumValueW#32 referenced in function
"public: virtual bool __thiscall ExHostAppServices::ttfFileNameByDescriptor(
class OdTtfDescriptor const &,class OdString &)"
(?ttfFileNameByDescriptor#ExHostAppServices##UAE_N ABVOdTtfDescriptor##AAVOdString###Z)
There's a lot of stuff in that error message (much of it may look like garbage). Fortunately, much of it can be ignored in most cases. The most important item is that the linker is looking for the symbol __imp__RegEnumValueW#32 The name has some gunk on it, but fortunately it's pretty recognizable anyway.
the __imp__ prefix indicates it's looking for a DLL import. In nearly all cases that can be ignored for your purposes.
the #32 suffix is something the Microsoft compiler adds to function names for certain calling conventions. It's also generally not important for your purposes (for the record it indicates that the function expects 32 bytes of argument data)
So we're left with the fact that the linker is looking for RegEnumValueW. That looks a lot like the name of a Win32 API.
If you look at the docs for RegEnumValueW (or RegEnumValue, since many Win32 APIs have both an A and a W variant to handle ANSI/UNICODE builds) we'll find in the documentation this bit of information:
Requirements
Minimum supported client Windows 2000 Professional
Minimum supported server Windows 2000 Server
Header Winreg.h (include Windows.h)
>> Library Advapi32.lib
DLL Advapi32.dll
Unicode and ANSI names RegEnumValueW (Unicode) and
RegEnumValueA (ANSI)
That's how you know you need advapi32.lib.
So in the future, when you get an "unresolved external" error from the linker, just ignore most of the gunk in the error message and concentrate on the symbol it says it can't find - that should lead you to the library, object file or other item you might be missing.
Just for the record, advapi32.lib will be needed by most Windows applications of any complexity.
you can try to use dependencywalker to see the list of dependencies for your dlls and see what it's missing.
have you entered the *.lib file in the linker options? (input --> additional dependencies"), and in addition the path to the .lib in libraries directories option?