PRINTDLG OR PAGESETUPDLG - mfc

i am trying to launch Printdlg() in my wince device but it is showing me linking error while building . this is the way i am doing it..
/// using pagesetupdlg....
PAGESETUPDLG info;
memset(&info,0,sizeof(info));
info.lStructSize=sizeof(info);
PageSetupDlg(&info);
or
////using printdlg...
PRINTDLG info;
memset(&info,0,sizeof(info));
info.lStructSize=sizeof(info);
PrintDlg(&info);
in both case it is showing me ---
error LNK2019: unresolved external
symbol PageSetupDlgW referenced in
function "public: void __cdecl
CAboutDlg::OnBnClickedButton1(void)"
(?OnBnClickedButton1#CAboutDlg##QAAXXZ)
PrinterTest.obj
plesae suggest me the solution...
regards,
mukesh

PageSetupDlg is definitely supported in the OS so that leaves two questions:
Are you linking to commdlg.lib?
Is the function included in your OS image/device SDK?
If #1 is true, then it's likely that #2 is false - at least it's not in the SDK. First, go look at the OS design. If you don't have access to that, you could try manually pulling it in - I'd try declaring it as an extern first and if that fails, try GetProcAddress.

Related

Error LNK2019 when building Tensorflow debug

I try make a debug build of the CPU version of the C++ API of Tensorflow 2.0 in Windows. The command I use for building is:
bazel build -c dbg --copt=/w34716 tensorflow:tensorflow.dll
But when I build this I get this error:
depth_space_ops.lo.lib(depthtospace_op.obj) : error LNK2019: unresolved external symbol "public: void __cdecl tensorflow::functor::DepthToSpaceOpFunctor<struct Eigen::GpuDevice,struct Eigen::half,1>::operator()(struct Eigen::GpuDevice const &,class Eigen::TensorMap<class Eigen::Tensor<struct Eigen::half const ,4,1,__int64>,16,struct Eigen::MakePointer>,int,class Eigen::TensorMap<class Eigen::Tensor<struct Eigen::half,4,1,__int64>,16,struct Eigen::MakePointer>)" (??R?$DepthToSpaceOpFunctor#UGpuDevice#Eigen##Uhalf#2#$00#functor#tensorflow##QEAAXAEBUGpuDevice#Eigen##V?$TensorMap#V?$Tensor#$$CBUhalf#Eigen##$03$00_J#Eigen##$0BA#UMakePointer#2##4#HV?$TensorMap#V?$Tensor#Uhalf#Eigen##$03$00_J#Eigen##$0BA#UMakePointer#2##4##Z) referenced in function "public: virtual void __cdecl tensorflow::DepthToSpaceOp<struct Eigen::ThreadPoolDevice,struct Eigen::half>::Compute(class tensorflow::OpKernelContext *)" (?Compute#?$DepthToSpaceOp#UThreadPoolDevice#Eigen##Uhalf#2##tensorflow##UEAAXPEAVOpKernelContext#2##Z)
The only thing I found regarding this issue was this GitHub issue, which wasn't solved.
Does anyone know how to solve this issue?
Facing the same necessity, I dug around in the code and actually found the source of the problem: It is contained in the following two if blocks: https://github.com/tensorflow/tensorflow/blob/v2.3.0/tensorflow/core/kernels/spacetodepth_op.cc#L129 and https://github.com/tensorflow/tensorflow/blob/v2.3.0/tensorflow/core/kernels/depthtospace_op.cc#L115.
If you are building a non-GPU version of the library in debug, it is sort of clear why the error happens: the if (std::is_same<Device, GPUDevice>::value) for the DepthToSpaceOp class, for example, parametrized with CPUDevice, would evaluate to if (false) during compile time. With any optimizations enabled, the code in the if-clause (which explicitly triggers DepthToSpaceOpFunctor with a template parameter GPUDevice - exactly the missing symbols you are getting) would not be compiled at all, and therefore not need to be linked.
In the debug build, it is still likely compiled, even though it is clear that it will never be executed. Then the linker tries to find the operator() for the DepthToSpaceOpFunctor template-parametrized with GPUDevice, and fails to do so.
A quick-and-dirty way to fix this is to comment out the entire if-clauses (if you are building a CPU-only dll) in both files mentioned above.
A more elegant solution is to avoid these linker errors via template specialization by changing the explicit references to GPUDevice to Device, since those will be in the code that is executed only when Device is GPUDevice. I will soon add a pull request to a similar issue I raised on github, hopefully, after a bit more testing.
Update: The pull request is submitted, you can find the code changes to fix this particular set of linker errors here: https://github.com/tensorflow/tensorflow/pull/42307/files#
For a GPU debug dll - I am not sure why these errors would still be there, but there are yet other linking errors in this case anyway ;)

libtorrent unresolved external

I'm getting the following error when I compile my program which links to libtorrent.lib. I've tried compiling libtorrent with different settings, I've tried enabling/disabling DHT, deprecated functions, etc.
error LNK2019: unresolved external symbol "void __cdecl
libtorrent::rel_performancetimer_pools_nolog_resolvecountries_deprecated_dht_ext_(void)"
Is anyone here familiar with libtorrent, or can anyone provide any advice for getting rid of this error? I don't see any other libraries that I need to link to.
Thanks in advance.
I've spent two days on it and finally I've found an issue.
Name of this function "void rel_performancetimer_pools_nolog_resolvecountries_deprecated_dht_ext_" consists of the parts, that describes your current preferences. For example, dht_ means you're using DHT, and nolog_ means you're switched off TORRENT_LOGGING directive.
The problem is: this settings works only with Release configuration! rel_ means release_. On the libtorrent 0.16.11 this problem still not solved.
I've put this text in file build_config.hpp on the line 40:
#ifdef _DEBUG
#define TORRENT_DEBUG
#endif
This is the way to compile my project with libtorrent in release and debug configurations, without making any corrections.
Arvid, please, include this 3 lines to your next version of libtorrent.
Appreciated,
Ilya from Russia.
The problem was that my definitions in my project were inconsistent with the configuration/definitions in the libtorrent compilation, so some macros were calling a function that doesn't exist.

Unresolved Externals Nightmare

Hello industry veterans,
I am a junior in college embarking on my first summer programming internship, and I am in way over my head. The company I'm working for has purchased a colossal application from another company that has slowly been expanding and modifying it since the early 90's. The solution contains over 200,000 lines of code which are spread across more than 300 files. The entire solution has purportedly been written to ANSI-C++ standards. The code is almost entirely undocumented, and most of it looks like hieroglyphs to me. Ultimately, my job is to port this code to embedded Linux. At the moment, my job is simply to get it compiling using Visual Studio 2008 on Windows XP.
Today, I'm running into linker errors such as this one:
libcmtd.lib(sprintf.obj) : error LNK2005: _sprintf already defined in msvcrtd.lib(MSVCR90D.dll)
My understanding is that this often happens when different projects within a solution are compiled using different runtime libraries. There are 6 projects in my solution. 4 of them were set to compile using the multi-threaded debug DLL runtime library (/MDd), one of them was set to compile using the multi-threaded debug library (/MTd), and one of them was set to compile using the multi-threaded dll runtime library (/MD). The first thing I tried after receiving this error message was to change the /MTd and /MD switches to /MDd so that everything would have compiled with the same runtime libraries. Unfortunately, this led to the following error in afx.h:
fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
After some digging around, I discovered that it had already told me what I needed to do. I went ahead and changed the "Use of MFC" option under Project Properties->Configuration Properties->General to "Use MFC in a Shared DLL". At this point I started receiving dozens of unresolved external errors such as these:
dataPropertySheet.obj : error LNK2019: unresolved external symbol "public: __thiscall CResizableSheet::CResizableSheet(unsigned short const *,class CWnd *,unsigned int)" (??0CResizableSheet##QAE#PBGPAVCWnd##I#Z) referenced in function "public: __thiscall CdataPropertySheet::CdataPropertySheet(unsigned short const *,class CWnd *,unsigned int)" (??0CdataPropertySheet##QAE#PBGPAVCWnd##I#Z)
ResizableLib.lib(ResizablePage.obj) : error LNK2001: unresolved external symbol "public: virtual int __thiscall CWnd::Create(char const *,char const *,unsigned long,struct tagRECT const &,class CWnd *,unsigned int,struct CCreateContext *)" (?Create#CWnd##UAEHPBD0KABUtagRECT##PAV1#IPAUCCreateContext###Z)
After reading through the MSDN pages on LNK2001 and LNK2019, I've realized I have no idea what's going on. These are not the sort of issues they've taught us how to deal with in school. I know my data structures, and that's about it. How I ended up where I am now is beyond me!
From my limited knowledge, it seems that the various debug and release versions of these modules are all tangled up in a web of preprocessor directives and #includes. There are a number of nested #ifdef checks and #define statements done in nearly every header and source file throughout the solution for environment variables, file names, macros, and possibly more. By making even small changes to my compiler settings, I seem to be redirecting large parts of the program to different libraries which have very different function definitions. This is my vague conceptual understanding of what's going on.
I feel as though I'm going to need a better understanding of how this code works before I stand any chance of troubleshooting these compiler errors. To that end, I've been trying to step through many of the files line by line to see where they lead, what objects and variables are in scope, and so on. Unfortunately, this doesn't get me very far, because every call to an external function is ambiguous, and I have no way of seeing through the preprocessor mess to know which version of any given function is supposed to be called.
I was looking around for magic solutions to map out the program and try to make sense of it. I tried one called Doxygen, but either I don't know how to use it properly or it's getting just as confused by the preprocessor stuff as I am.
My question is this:
What are my remaining options?
At this point it's a toss up between:
a.) Switch majors
b.) Jump off a bridge
Neither of these choices are going to help me better understand this code base and get it compiling. Does anybody have any better ideas? Similar experiences? Sage wisdom to share?
Thanks a ton,
-Alex
It appears you're using the CResizableSheet and CResizeablePage from CodeProject. If you're using the compiled static lib from that page, you could try downloading the source and compiling that with the matching /MDd setting and using the .lib it outputs in the linker input section of your project. I'd also suggest doing a clean all (go to build->batch build->select all then click clean) and then try building again to make sure everything is up to date.
I hear nursing is a great program ...
At the risk of being pedantic, what you are fighting with are linker errors, not compiler errors. My basic approach to this would be to create a new solution, and start adding projects one at a time, getting each one to build in turn.
I would also seriously consider trying to standardize the settings of each project as much as possible. The easiest way to do this is to create empty projects in your new solution, and copy the existing code into them.
To start with you should assume the following settings (related to MFC):
Debug: Use MFC in a shared DLL, /MDd
Release: Use MFC in a shared DLL, /MD
MDd and MD are the same mode, but one links against debug libraries with extra information for debugging.
Then all you can do is work on one project at a time. Note that if you create a new solution as suggested, you'll need to rebuild the dependency tree between projects. (Right click on a project and choose 'Dependencies', you'll see what I mean.)
When you run into problems doing this, you should make friends with a senior developer at your workplace =).
Compile everything with the same runtime libraries. End of story.

Ogg/Vorbis: _ov_fopen cannot be found

I'm trying to use Ogg/Vorbis with OpenAL to get sound in my game. Right now I'm simply trying to load a .ogg file and read its data, I'm not actually doing anything with it. I first tried using ov_open, however, the documentation said I should really be using ov_fopen on Windows.
However, when I try to use that I get the following:
1>AudioManager.obj : error LNK2019: unresolved external symbol _ov_fopen
referenced in function "private: static struct SomeGame::SoundData * __cdecl
SomeGame::AudioManager::LoadOGG(char *)"
(?LoadOGG#AudioManager#SomeGame##CAPAUSoundData#2#PAD#Z)
...and when I Google "unresolved external symbol _ov_fopen", I get exactly one result. And it's in Japanese.
So I tried downloading the ogg and vorbis source and compiling it, and inserting those in the project, but it still gives me the same error.
Basically, how do I load in an Ogg/Vorbis file to be used with OpenAL on Windows?
Thanks in advance.
Are you linking with libogg, libvorbis and libvorbisfile?
Further to SurvivalMachine's answer;
Dependency Walker shows _ov_fopen is definitely defined in libvorbisfile.dll
Or on linux, "nm libvorbisfile.a | grep _ov_fopen" shows _ov_fopen is defined there.
#include <vorbis/vorbisfile.h>
Make sure your linker knows where to find the lib file.
Note that you'll need to either compile with -Wunused-variable or;
#define OV_EXCLUDE_STATIC_CALLBACKS
...before the include.

How to create a fixed back-end DLL for Pantheios logger

I have a VS 2005 solution that has numerous projects (most are DLL, 1 EXE which is a CppUnit project) and I am trying to add a fixed back-end DLL for the Pantheios logger so that I can use a single logger instance throughout the solution. Following the directions from the below URLs:
Use Pantheios logging framework from a dll
https://sourceforge.net/projects/pantheios/forums/forum/647484/topic/1639420/index/page/1
I seem to have a fixed back-end DLL that supports basic Pantheios logging statements e.g. log_DEBUG, log_ERROR etc. and even the Tracing API (http://www.pantheios.org/doc/html/group__group____tracing.html) e.g. PANTHEIOS_TRACE_NOTICE.
But I am stuck going forward because Pantheios requires "inserters" (an API to convert fundamental types to string) (http://www.pantheios.org/doc/html/group__group____application__layer__interface____inserters.html) to handle for example int, double, float, pointer etc.
I don't know how implement these "inserters" in the fixed back-end DLL that I created. If I simply call them from my other DLLs then I get an error such as this:
DLLApp.obj : error LNK2019: unresolved external symbol "public: __thiscall pantheios::integer::integer(int,int)" (??0integer#pantheios##QAE#HH#Z) referenced in function "public: void __thiscall DLLApp::DLLAppSetup(void)" (?DLLAppSetup#DLLApp##QAEXXZ)
I am not sure if I can (and need to) export the "integer" (and other inserter) class using the .DEF as mentioned in the sourceforge.net article OR if there is something else I am missing.
Any help would be most appreciated. Thanks in advance.
In project properties page, change character set as "Use Multi-Byte Character Set"