This is a very specific problem, - I apologize for that.
I've been building a graphical real-time application using Direct3D 11. I started it on the Win7 OS. I then upgraded to Win10 and when I tried compiling the solution again, the linker barfed like it had caught the plague for silicon microchips.
It spews out Unresolved symbols in objects that don't even use the given functions.
__imp__wassert
strlen
fabs
__imp__CrtDbgReportW
sprt
and more
I've concluded that the majority of the functions in question is mostly C functions. I'm aware that the c functions are no longer included in the C++ headers and libraries, so I made sure to include all the relevant C-libraries explicitly.
I've read and followed the solutions of some of most of the other folks having problems with Windows 10 screwing their code. one of them is this : Upgraded to Windows 10 and now WAMP won't work
I also tried actually telling the linker where to look for the -lib-files, in case the compiler or project missed the memo.
On my PC, the location for the Direct3D libs is here: C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10586.0\um\arm64
As you can see, I am trying to force it to use Win10 lib versions in case this was a requirement.
I started in one end to try and catch myself doing something stupid:
I looked for full include paths to see it this had started an avalanche: FAILED
I tried removing the /ZI compiler option: FAILED
Relinking the DirectX libs to all different version one at the time: FAILED
Explicitly include the vcrumtime.lib to the additional linker libs: SUCCESS (removed half the errors)
Create An entirely new project and include everything from scratch: FAILED
Add MSVCRTD.lib : FAILED
Change the target platform to 64bit: FAILED
Tried including stdio.h in certain independant tool classes: FAILED
Tried including Winmm.lib in the linker: FAILED
I've roamed the internet for what feels like a decade (only a month irl) to find some solution, but nothing.
I hope some of you have an idea of what noobiness I might have committed.
All suggestions will help.
Most likely you are linking with a static library that is not compatible with VS 2015 because it uses the Universal CRT. For example, the legacy DirectX SDK library DXERR.LIB fails to link when using VS 2015. Make sure you rebuild all your code with VS 2015 and avoid the use of static libraries build for other versions of Visual C++.
You also won't be able to get your project to link and run on an x86 or x64 PC linking with the 64-bit ARM libraries.
You do not need to use the Windows 10 SDK for Win32 desktop apps, although you certainly can.
Related
I need to configure Thrift for Eclipse project with MinGW compiler. I googled for it. I couldn't find proper instructions to do that? Can somebody suggest any suitable way or proper link to do that?
There are several partial answers to this.
The Windows build is made by means of MinGW cross compiler on a Linux machine.
Since (at least) 0.9.2 it is no longer necessary to use MinGW to build the Thrift compiler on a Windows machine.1) Aside from the fact, that you don't need to do that at all, because a precompiled EXE is available on the download pages, there is a nice Visual Studio project to build the Windows Thrift compiler EXE. The project has only two dependencies: Bison and Lexx/Yacc, which are both available elsewhere as precompiled Setups as well.
In either case MinGW is only used to build the compiler. If you want to build the libraries with MinGW, I'm not sure if that even works. This way of doing things is not implemented or supported, simply because nobody needs it.
Which brings us back to the question, why you think you "need" it this way.
1)To my knowledge, numerous severe problems exist with the autotools and all the stuff needed to build Thrift under MinGW on a Windows machine. You will have to patch things, build some from source, spend a lot of time and do some strange things with your file system to make it work. At least that was the case when I stopped using MinGW to build Thrift about two years ago. And even if you get it to work, you still only get the compiler (which you could easily download in a fraction of that time), not the libraries.
Lots of questions out there on trying to get NVCC to use the intel compiler. It doesn't work, I get that.
The most common answer that people give is to compile the device code into a library using NVCC/cl.exe and then compile the host code separately and link them. I'm attempting this, but am getting nowhere.
In VS2012 I have created a solution with 2 projects - one CUDA, the other a console application.
I have set the CUDA project to compile with VS2012 into a static library. It compiles no problem.
I have set the console application to intel 14.0 and to compile as an exe. I have also added the correct path to "Additional Library Dependencies" and have told the compiler about the CUDA library through "Additional Dependencies" (where I also told it about cudart_static.lib).
Build dependency is also set to compile the CUDA project first.
However, this setup is no good. Gives me an error which even google is at a loss for:
Error 5 error MSB4057: The target "ComputeLegacyManifestEmbedding" does not exist in the project. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\Win32\PlatformToolsets\Intel C++ Compiler XE 14.0\Toolset.targets 1162 7 rxnCalc_cpp
To verify that the linking is ok, if I set both projects to compile via VS2012 I get no problems.
OS - Windows 7 64bit (32bit application though)
Platform - VS2012
Cuda Toolkit - 6.0
Cuda Compute Version - 5.0 (and compiled as such)
So, am I just wasting my time or is there something I'm missing? It seems I have gone through a hundred posts, but I have yet to see a single success. Lots of people anxious to tell you that this is what you should do, but no one to tell you how to do it!
For everyone out there using windows and trying to get CUDA and the intel compiler to co-operate, see my initial question on how I set up the solution.
To get it to work, as per Roger Dahl's suggestion, I changed the CUDA project to a DLL.
This involved the following modifications:
Change CUDA project to dll
Add __declspec(dllexport) to CUDA wrapper function
Point console linker to the DLL lib file
This works and I am now able to utilize all intel compiler optimizations.
However, please note, I did need to set the intel compiler to only do single file IPO. Multi file IPO will cause errors, this was somewhat expected.
Hope this helps others in the same boat.
So I have been programming in console C++ for a while, but I finally decided to try graphical applications using OpenGL. It took me a while to learn that GLUT and other libraries are obsolete, so I began installing and preparing GLEW and FreeGLUT. I managed to get to the point were my includes are working; however, now I'm running into this problem:
Visual Studio is telling me that I don't have glew32.dll when it is clearly sitting in the system32 folder. Is this not the default folder for these libraries?
In addition, every time I run my program (and hence get this error) the visual studio process continues running in the background, even after the program is closed. It refuses to be ended and it causes another problem: whenever I reenter Visual Studio I get a message saying that the default storage location is currently in use by another instance of visual studio (the one running in the background.) As a result, to continue working I have to restart my computer every time.
Does anyone have any clue what could be wrong with this and how I could get things up and running? This is my first time installing libraries, but I haven't touched random things in the system folder (at least not intentionally) and I've been careful to clean up behind myself when I've done something I shouldn't have.
Other info:
Visual Studio 2012
Latest stable releases of freeGLUT and GLEW
Windows 8.1 64bit
There are a few things worth mentioning here:
You really should not even bother with using the dynamic linking version of glew (glew32.lib). Just link against the static linking library (glew32s.lib) and forget that the DLL version ever existed.
The DLL version is more trouble than it is worth, especially since it will not work with other compilers (e.g. g++) on Microsoft Windows.
For goodness' sake, do not install glew32.dll to System32!
Never, ever, put any user DLLs there. This is the primary cause of "DLL hell." What you should do is distribute them along with your application instead (e.g. in your .exe's working directory) or if the software has a run-time redistributable installation program (glew does not) ship that with it.
I am willing to bet good money you are running a 64-bit version of Microsoft Windows.
You are compiling a 32-bit application, and it will run in Microsoft Windows' 32-bit compatibility layer known as Windows on Windows. All 32-bit DLLs will be sourced from a separate location SysWow64 when running in the compatibility layer.
This can be confusing, as you would think that System32 means 32-bit... but for historical reasons System32 actually contains the DLLs for the native version of Windows (32-bit on Win32 and 64-bit on x64).
Nevertheless, do not install glew32.dll to SysWoW64 either :)
Since you mentioned in comments that you do not understand what "linking against glew32s.lib" means, I will tell you simply that this line in your header file is causing the linker to use the DLL version of glew:
#pragma comment (lib, "glew32.lib")
This is an ugly hack for the Microsoft Visual C++ compiler that tells the linker to add this as a dependency. It is not understood by other compilers (e.g. g++), but if your software is always going to be compiled with Visual Studio you can continue to use it.
To change your software to use the static (non-DLL) version of glew, simply replace that line with this:
#pragma comment (lib, "glew32s.lib")
Now you do not need to distribute a DLL along with your program and this whole problem effectively disappears.
I wrote a C program and works fine on Windows 7 and Linux, but when I execute it on Windows XP I get the error:
"_except_handler4_common could not be located in the dynamic link library msvcrt.dll"
I researched it and some people said to delete the DLL "dwmapi.dll" which I don't have, so that's not my problem.
Some one told me to use depends walker(depends.exe) to find who is using msvcrt.dll. I did and find that pcre library is using it and there actually is a problem with it, but I don't have any idea how to solve this. Can any one help me?
Here's image of what depends walker show me:
Reason possibilities (afaiu):
a) You linked to msvcrt.dll specifically when building - this should
not happen according to Microsoft support unless you specifically do
it.
b) Some other installed or copied program/driver on your XP that
links to "wrong" version of msvcrl.dll is being triggered.
Depending on what the reason is,
here are few ideas to resolve:
1) There might be some program/driver/etc. installation on your XP
machine that has introduced "Vista/Win7 related crap" onto it. It is
said (by the internets) that PCRE3.DLL belongs to "GnuWin32 Non-system
processes". That means you can try to find it and rename/delete it. Or
delete the program you that uses it.
2) Installing the redist for XP of the C++ redistributable that you
used to build on Win7 might help. This is link for VS2005: (darn..
use google - i can only give two links per post :P)
Rebuilding:
3) Just build the file from sources on your XP machine using some
VisualStudio version you can get on it. And check those VS project
properties!
4) Fix your build on Windows7. You might be linking to
_except_handler4_common in msvcrt.dll in your Windows 7 build. Make sure that you do not do that. You can specifically instruct the linker
not to link to it in VisualStudio project properties
"/NODEFAULTLIB:msvcrt80.lib". You also did not specify what are you
using for building. VS2005, VS2008, VS2010, gcc?
Answer based on educated guesses and Jeffrey Tan research here:
and research here:
(On behalf of OP)
The problem was with the pcre3.dll, as i've told before, and i simply change the version of it, I was using the version 7.x and change to 4.4 that calls pcre.dll instead of pcre3.dll, that solve my problem if any one have the same issue.
here is the link to the correct lib:
pcre-4.4-dll.zip
Here's my configuration:
Computer A - Windows 7, MS Visual Studio 2005 patched for Win7 compatibility (8.0.50727.867)
Computer B - Windows XP SP2, MS Visual Studio 2005 installed (8.0.50727.42)
My project has some external dependencies (prebuilt DLLs - either build on A or downloaded from the Internet), a couple of DLLs built from sources and one executable. I am mostly developing on A and all is fine there. At some point I try to build my project on computer B, copying the prebuilt DLLs to the output folder. Everything builds fine, but trying to start my application I get
The application failed to initialize properly (0xc0150002)....
The event log contains two of those:
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
plus the slightly more amusing
Generate Activation Context failed for
some.dll. Reference error message: The
operation completed successfully.
At this point I'm trying my Google-Fu, but in vain - virtually all hits are about running binaries on machines without Visual Studio installed. In my case, however, the executables fail to run on the computer they are built.
Next step was to try dependency walker and it baffled me even more - my DLLs built from sources on the same box cannot find MSVCR80.DLL and MSVCP80.DLL, however the executable seems to be alright in respect to those two DLLs i.e. when I open the executable with dependency walker it shows that the MSVC?80.DLLs can be found, but when I open one of my DLLs it says they cannot. That's where I am completely out of ideas what to do so I'm asking you, dear stackoverflow :)
I admit I'm a bit blurry on the whole side-by-side thing, so general reading on the topic will also be appreciated.
Your question has the answer to your problem: Computer A has VC runtime of version 8.0.50727.867, and Computer B has only version 8.0.50727.42.
You built your libraries on Computer A, and they depend on version 867 of VC runtime. (This can be found in manifest embedded in the libraries.) When you copy them to Computer B, these libraries still require version 867 of the runtime but you have only version 42.
To resolve the VC runtime assembly dependencies, you have to install VC runtime redistributables of version 867 on Computer B. However, I'd advise you to update Visual Studio on Computer B so that you have the same version on both computers. And even better, install Visual Studio 2005 SP1 on both computers and then install this security update to SP1. After installing the latter, your libraries will depend on version 8.0.50727.4053.
it's possible the problem is related with different versions of CRT runtime installed on both machines. is it possible to build all your modules to use statically linked CRT runtime to verify this?
first I'd check that prebuilt dlls by preparing dummy project to load them
I recently had the same type of error when building projects on one machine and then moving them to another machine. The biggest culprit here is likely a debug configuration for one of the binary components. That is, MSVC has the fairly rigid requirement of all DLLs/EXEs being built with the same runtime library, debug or release, otherwise they will not work together.
When I had this happen they also tend to compile just fine, but when you attempt to run them you get that extremely cryptic error message.
You need to ensure that every module you build together uses the same configuration, thus debug or release through the entire build chain. This error also likely comes up with mismatches in other libraries, so make sure your MSVC is the exact same version on the machines where you are building.