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.
Related
So, I have problem, when try to use any of static members of SFML Library like sf::RenderState::Default or sf::Color::Blue.
error LNK2001: unresolved external symbol "public: static class sf::RenderStates const sf::RenderStates::Default" (?Default#RenderStates#sf##2V12#B)
But when I comment lines, I have access to sf::window (it be created, but can't draw anything, because sf::Drawble has sf::RenderState::Default as standart argument).
I checked everything including linker and compiler in Solution properties in Visual Studio (I have VS19).
P.S. I use the latest version of SFML (2.5.1) and Visual C++20.
Thanks for your help.
The troubleshooting steps I would undertake in this situation go from easiest to the inverse of that.
If I check the declaration of sf::RenderState::Default, can it be found?
If I create a new project with just this feature used, does the error persist?
If I redo my linking and directory searches, is the problem fixed?
Do I have a version compatible with my compiler?
Furthermore, the amount of information you've given about your environment is not enough to speculate on what the issue could be. It might be helpful to post your version of SFML, your compiler (and kind), what your project is like (shorthand.)
SFML can be compiled from source if necessary. Sometimes, using an incompatible version on accident will not show any issues on many basic things until you run into weird errors.
See this document on compiling SFML from source:
https://www.sfml-dev.org/tutorials/2.5/compile-with-cmake.php
So, thanks for AlixianaBritmonkey, I managed with this problem. I just create new project and moved every file. I don't know why problem occured before, but my solution helped.
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 ;)
I'm using C++, and compiling & linking to OpenCV2 using "g++". One thing that bothers me is that all of the old cv-prefixed functions are still available and "pollute" my application.
Is it possible to make the OpenCV1 C cv-prefixed functions unavailable in the scope of my application and just keep the OpenCV2 cv:: namespaced ones?
Note: I haven't written C in a while, so please let me know if this is a silly question.
It depends on what do you really need. If you just want to make this code:
CvArr *arr;
cvAvg(arr);
cvAcc(arr, arr);
"not working" - you can just add this:
#define cvAvg nothing_interesting_cvAvg
#define cvAcc nothing_interesting_cvAcc
//you can change nothing_interesting_... to anything, but you can't use the same text more than once
//you include files
//...
//after your include files
#undef cvAvg
#undef cvAcc
before including any OpenCV file. If you now try to compile code you will see:
error C3861: 'cvAvg': identifier not found
If you change you code to use nothing_interesting_cvAvg(arr); instead of cvAvg(arr);, it will compile fine, but linker will fail, because:
: error LNK2019: unresolved external symbol _nothing_interesting_cvAvg referenced in function _main
Note that this will work only for this 2 functions, so you will have to find all functions which you want to "disable" and write similar code manually.
Functions which use "deactivated" functions will work fine, because they are already compiled, linked, etc - you will just call them from some files without changing anything in this files.
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.
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.