I get this error. My program files contains CLR3.0 and CLR4.0. I have tried to remove the CLR3.0 folder but then another error is coming out.
This is the error message displayed when have both CLR3.0 and CLR4.0 folder:
The type 'Infragistics.Windows.Editors.ComboBoxItemsProvider' exists in both 'c:\Program Files\Infragistics\NetAdvanatage 2011.1\WPF\CLR3.0\Bin\InfragisticsWPF3.Editors.v11.2.dll' and 'c:\Users\myname\Documents\Project\Projects\Ion\Ion\Dev\ThirdParty\InfragisticsWPF4.Editors.v11.2.dll'
The error that you are getting is because both the 3.0 and 4.0 assembly are being loaded. Since both versions of the assembly have the same types, the compiler doesn't know which one to use.
To fix this you will need to remove all references to the 3.0 assemblies. Check both your references and references for each dependency.
Related
I'm trying to load a DDS texture. For that, I'm using DDSTextureLoader11 provided by DirectXTex. I already am using another texture loader from the same library - WICTextureLoader11.
The problem is, I don't get errors with WICTextureLoader11, however I do get errors either when including only DDSTextureLoader11, or when I use both of them.
This is some of the errors I get when I include both or only DDSTextureLoader11:
/WICTextureLoader11.cpp:51:17: error: redefinition of 'SetDebugObjectName'
/WICTextureLoader11.cpp:273:17: error: redefinition of 'MakeSRGB'
/WICTextureLoader11.cpp:747:17: error: no matching function for call to 'SetDebugObjectName'
/DDSTextureLoader.h:156:35: error: redefinition of default argument
I first thought that it was because both WICTextureLoader and DDSTextureLoader contain same functions, so when including both they "overlap" (i.e. compiler detects redefinition).
I'm using a batchfile to compile my project, where I link against both DirectXTex and DirectXTK. I also tried to include DDSTextureLoader, but without success: I've read the GitHub page of the DirectXTK's DDSTextureLoader, where I include <DDSTextureLoader.h> that gives me a link error, which I guess is related to the incorrect call of the function CreateDDSTextureFromFile, so right now I'm trying to find a way to make the right call to the function.
Edit: no, it seems like I'm making the right function call. The wrong thing is that I'm trying to include DDSTextureLoader.h, but it also wants DDSTextureLoader.cpp. However, the errors occur when I include DDSTextureLoader.cpp, such as:
'DDSTextureLoader.cpp': call to 'BitsPerPixel' is ambiguous -> 'DirectXTex.h' or 'DDSTextureLoader' error: redefinition of 'SetDebugTextureInfo', previous definition in 'WICTextureLoader'.
I think, what I need is to include the .cpp file, but somehow get rid of the errors.
Edit2: So far, I tried to get rid of DirectXTex (I don't remember why I even needed it), and I've included WICTextureLoader.cpp and DDSTextureLoader.cpp. I downloaded and built the DirectXTK library, then included #pragma comment(lib, "directxtk.lib"). Now, the weird thing is: when I compile with Clang++, it doesn't throw any errors (but the program crashes after a second-long gray screen), however when I compile with cl (through vcvars64), I get fatal error LNK1104: cannot open file 'directxtk.lib'.
Edit3: Wait, I don't even know why I even need the directxtk.lib. So I removed it, and it compiles, but nothing works. I thought I needed that static library to resolve external symbol errors when trying to include the header (XXXTextureLoader.h), instead of the source (XXXTextureLoader.cpp).
Edit4: Wait,wait,wait. I think, I'm going crazy. Now, if I include only WICTextureLoader.cpp (and remove DDSTextureLoader.cpp), it gives me this error: (directxtk.lib) mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease'. I don't know why I did that, but I'm crazy now, I blindly brute-force my way through resolving this cursed issue. Why can't I just throw both headers in my directory and just simply include them? Is there a way to do so? What should I do? Why doesn't DirectXTK/Tex pages on GitHub give a step-by-step guide to how to use these things? The examples drive me crazy!
Please, help me resolve this what seems to be a simple issue.
Edit5: The last thing that I tried is to include DDSTextureLoader.h and WICTextureLoader.h, and use directxtk.lib, but it gives me these errors:
directxtk.lib(DDSTextureLoader.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main-3dacd8.o
directxtk.lib(pch.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main-3dacd8.o
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
I don't use VS, so I don't know how to use /NODEFAULTLIB.
You have three choices for loading DDS and other image files with WIC:
Use DirectXTex (the library)
Use DDSTextureLoader/WICTextureLoader (the standalone versions)
or use DirectX Tool Kit (the library).
There's no reason to use more than one of them in the same program, and it's going to conflict if you try. See this post.
Unless you are writing a texture processing tool, or need support for the plethora of legacy DDS pixel formats, using DirectX Tool Kit is usually the simplest. The tutorials for DirectX Tool Kit covers this pretty well.
The error you are getting indicates something much more basic to using Visual C++. The DirectXTex, DirectXTK libraries build using the recommended "Multithreaded DLL" version of the C/C++ Runtime (i.e. /MDd and /MD).
The error indicates your program is building with "Statically linked" version of the C/C++ Runtime.
See Microsoft Docs
You didn't mention what compiler toolset you are using other than "not VS".
See directx-vs-templates for a bunch of 'basic device and present loop' samples. If you don't use VS, there are 'CMakeLists.txt' available on that site.
I was confused once again with DirectXTex and DirectXTK.
I resolved the issue by:
Removing DirectXTex
Downloading DirectXTK
Running the DirectXTK_Desktop_2019_Win10 solution
Changing the Build to Release and x64
Opening the properties
Finding the option Runtime Library
Choosing Multi-threaded /MT
Building the solution
In my source file, I include:
#include <WICTextureLoader.h> and #include <DDSTextureLoader.h>
I can now link to the generated static library directxtk.lib, without getting errors.
Plus. If there are people who want to use things like /NODEFAULTLIB:library, but you don't use cl or Visual Studio, you can use the #pragma directive in your source file like this:
#pragma comment(linker, "/NODEFAULTLIB:MSVCRT")
I have an application which uses a class Foo from an .so shared library. I've come across a problem where at runtime it prints
<appname>: symbol lookup error: <appname>: undefined symbol: <mangled_Foo_symbol_name>
Now, it turned out that the unmangled symbol was for the constructor of the class Foo, and the problem was simply that an old version of the library was loaded, which didn't contain Foo yet.
My question isn't about resolving the error (that's obviously to use the correct library), but why it appears at runtime instead of at time of load / startup.
The line of code causing the error just instantiates an object of class Foo, so I'm not using anything like dlopen here, at least not explicitly / to my knowledge.
In contrast, if I remove the whole library from the load search path, I get this error at startup:
<appname>: error while loading shared libraries: libname.so.2: cannot open shared object file: No such file or directory
When the wrong version of gcc / libstdc++ is on the load path, an error also appears at starup:
<appname>: /path/to/gcc-4.8.0/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by <appname>)
This "fail fast" behavior is much more desirable, I don't want to run my application for quite awhile first, until I finally realize it's using the wrong library.
What causes the load error to appear at runtime and how can I make it appear immediately?
From the man page of ld.so:
ENVIRONMENT
LD_BIND_NOW (libc5; glibc since 2.1.1) If set to a nonempty string, causes the dynamic linker to resolve all symbols at program startup instead of deferring function call resolution to the point when they are first referenced. This is useful when using a debugger.
LD_WARN (ELF only)(glibc since 2.1.3) If set to a nonempty string, warn about unresolved symbols.
I think you can not statically link .so library. If you want to avoid load/run time errors you have to use all static libraries (.a). If you do not have static version of library and source then try to find some statifier. After googling I find few statifiers but do not know how do they work so leaving that part up to you.
This is a strange error. When I run my code, I had to update the location of ulldiv.asm via
implementation of unsigned long long division
the line in question matched exactly the one used in the link:http://objectmix.com/c/68732-dynamic-memory-allocation-c.html
tim = (__time64_t)((nt_time.ft_scalar - EPOCH_BIAS) / 10000000i64);
Anyways, the first link gave me the right answer and I relocated ulldiv.asm to C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\crt\src\intel\ulldiv.asm.
Now when I run my code this line gives me trouble
double NOISE_SIGMA = NOISE_DENSITY*sqrt(SYS_CLK_FREQ);
the sqrt function becomes undefined (?). The debugger stops and asks me for the location of sqrt.asm.
You need to find sqrt.asm to view the source for the current call stack frame
This is a similar error that I found in a German website: http://www.c-plusplus.de/forum/324725-full
but it doesn't seem to get resolved there.
I don't understand what's going on. If you need more information regarding the code, let me know. Thank you in advance.
If it makes any difference I step through my code using F11.
While most of the source files for the Visual C++ libraries are included with the Visual Studio installation, some files are not included. Notably, the sources for the math library are not included.
The fact that the debugger cannot automatically find ulldiv.asm is a bug; this has been fixed in Visual Studio "14" (I think the fix was present in CTP1; I know for sure the fix is present in CTP3 which was released today).
Sometimes VS autos/locals/watches break and instead of variables/values all I have is different kinds of:
CXX0029: Error: not struct pointer
CXX0033: Error: error in OMF type information
CXX0072: Error: type information missing or unknown
CXX0025: Error: operator needs class/struct/union
Rebuilding project, cleaning PDB/NCB etc doesn't solve it. What can I do?
Look at this Microsoft support note on: FIX: CXX0033 Error in OMF Type from Forward Class Declaration
Once you fix the PCH problem cited in the support note, I think all your errors will go away.
There is in fact a solution that lets you keep using precompiled headers: check out this more recent KB article and the documentation of the /Yl switch - which seems specifically tailored to this error.
Just add to the stdafx.cpp (or your own custom /Yc file) command line '/Ylxxxx', where xxxx stands for an arbitrary function name in your lib.
I recently faced symptoms identical to yours (in VS2010), and that solved it for me.
Are you trying to debug the "release" build? If so, many local variables will not exist as "debuggable" elements. You can get around this (if you must debug the release build) by debugging at the assembly level and look at the register values (vs. stack values, where auto/local would be in the debug build) and cast them appropriately in the "watch window".
Otherwise, build the Debug build and debug that build version. You'll get assertions where preconditions are not met, relevant/irrelevant stuff dumped to your output window, and more straight-forward debug single stepping.
It helped me to switch from using a program database (/ZI) to "c7 compatible" (/Z7). Switching off precompiled headers did not make a difference. Neither did rebuilding.
When I point to my C++ dll from DependencyWalker, I see the error message "At least one module has an unresolved import due to a missing export function in an implicitly dependent module"
Can you please suggest what the error is?
Your dll (or a dll that it imports) has an import from another dll (bad.dll say). When DependencyWalker scans bad.dll it finds that it does not export the required function. This missing export will be labelled in red (or somesuch) in your dll's import list.
View → Undecorate C++ Functions might be useful to you.
To discuss further #bobbogo's answer, you need to have the exact same symbol in the child library as the one needed by the first library.
For example I had a problem because opencv_highgui455.dll needed the function QTest::keyToAscii, found in Qt.
QtTest6.dll had the correct function in it, but not the exact same symbol, because this version of Qt was compiled with mingw and opencv was compiled with Visual Studio. Thus the dll could not share their symbols and understand each other.
You can see this either by doing:
strings "[opencv4.5.5]\x64\vc16\bin\opencv_highgui455.dll" | grep keyToAscii
# returns ?keyToAscii#QTest##YADW4Key#Qt###Z
strings "[qt6]/msvc2019_64/Qt6Test.dll" | grep keyToAscii
# returns ?keyToAscii#QTest##YADW4Key#Qt###Z
strings "[qt6]/mingw_64/Qt6Test.dll" | grep keyToAscii
# returns _ZN5QTest10keyToAsciiEN2Qt3KeyE
or you can directly see that in Dependencies (note the red card or the green card, and the Demangler):