I'm using OpenGL under VS2010 doing a program for a long time. The program can always run independtly(I mean not run from vs2010 but double click out side of the IDE) until now. "missing glut32.dll" shows to make me put it under the same directory.
Some one may say that I may losing glut32.dll in system32(or in my case, syswow64 for 64 bit windows). It is proved true when I put it in the dir. The question is: I've never removed it before. How can it be that case?
glut32.dll is not a core system library. It's not installed there by default. Maybe some program's installer did put its own copy into the system directory and removed it on uninstallation.
Anyway, glut32.dll is not a standard library and as such it's not a bad thing to ship an independent copy with your own program.
You must put the glut.dll files in:
C:/Windows/SysWOW64
This is the folder where 32-bit .dlls are located.
C:/Windows/System32 contains the 64-bit .dlls.
You can also put the GLUT.dlls in System32, if you want to feel safe.
You could've just uninstalled something. I think it shouldn't be there in the first place, since it isn't some sort of standard library.
Anyway, it's always wise to supply all of the libraries needed by your program. You can have multiple applications using GLUT in different versions, so it's best bet to just keep it close to executable.
Copy and paste the file glut32.dil in location C:\Windows,
it will fix all your problems.
If this does not work, then follow the steps below:
Go to settings->compiler->linker settings->add C:\MinGw\lib\glut32.lib then PRESS ok.
Go to settings->compiler->Toolchain executables->C:\Program Files (x86)\CodeBlocks\MinGW
then copy and paste the file glut32.dll in location C:\Windows
In W10 (64b), glut32.dll is not installed as standard and the convention seems to be "go find the source and compile it" (assuming like me you have an aversion to getting it off generic dll download sites).
Eventually, after visiting https://opengl.org/resources/libraries/glut/ , I found http://vis.eng.uci.edu/~jkimball/eecs205/glut.html which has a link to the DLL at https://user.xmission.com/~nate/glut.html
Oddly, regsvr32 would not register it, but dropping it into c:\Windows\SysWOW64\ worked fine.
Not to be confused with glu32.dll which is already there.
Hope this helps. Pls don't be rude by downvoting without explanation or modifying my reply for brownie points. I am trying to do you a favour.
Related
My current task is to set up a working environment for an application using (static) Qt and VTK, under Windows 10.
I successfully installed the Qt 5.11.1 static and now want to build VTK. Any version of VTK does, as long as it is compatible to Qt 5.11.1, and the Qt Modules (VTK_Group_Qt) have to be build. For my version, I decided on VTK 8.1.1, but as said, any version would do.
I used the CMake GUI to configure VTK, using MinGW Makefiles (I use a MinGW64), which worked. Then I wanted to proceed generating the Makefile, having turned on VTK_Group_Qt. The paths and version of Qt were already correctly recognized:
Qt5Core_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core
Qt5Gui_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Gui
Qt5Widgets_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Widgets
Qt5_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5
Made sure that all of those exist. After that, I hit Generate and got the following error:
The imported target "Qt5::Core" references the file
"C:/build_environment/qt-everywhere-src-5.11.1/qtbase/.../qt-everywhere-src-5.11.1/qtbase//mkspecs/win32-g++"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core/qt5CoreConfigExtras.cmake"
but not all the files it references
Now, we see that it goes one folder upwards from qtbase and then into the very folder it currently is in, which of course is not a legitimate path. That is, for some reason it tries to go up and then down again, but not with the right amount of folders.
I could try to move the contents of my Qt installation so that the path would be legitimate, but I'd consider that to be pretty much of a smell. Fiddling around in a folder structure that should be correct is not what I understand to be a good solution. I'd rather be willed to change one of the .cmake files of Qt, but that would also be more of a makeshift approach than a real solution as far as I am concerned.
One thing I tried so far was to look at all the CMake variables (checking Advanced in the CMake GUI) in order to see if everything appear to be in order, and especially to see if that faulty path to mkspecs is to be found somewhere there. Found nothing of particular interest.
Does anybody have an idea what went wrong? Tell me if additional information is required. In parallel, I will try to build other versions of VTK, but I'm not too confident that this will solve the issue.
I found a solution which I want to present here, but I consider it a makeshift approach rather than an actual solution, and I hope to see a better answer.
I went to qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core/ and changed the file Qt5CoreConfigExtrasMkspecDir.cmake (after making a copy).
The original file contains a single line
set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/.../qt-everywhere-src-5.11.1/qtbase//mkspecs/win32-g++")
which leads to the faulty path. I changed it to
set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/mkspecs/win32-g++")
And it now works fine. Still, I don't feel good about having to change a file of Qt, since I consider the answer the question "Is this famous library at fault?" to be "Most likely I used it wrong."
A possible explanation would be that I used the wrong install prefix when configuring Qt, but shouldn't I be allowed to put any valid writeable path in there? Plus, the prefix is still in the cmake file and thus has some validity.
While this is an answer since it fixed the problem, I'd really like to read comments about what could have originally went wrong.
I tried to run a program I wrote on a remote computer. As I knew there might be a dll problem, I set the runtime library option to /MT, so I can rely on static linking.
However, I still receive the error message on my remote computer, stating that MSCVP140.dll is missing. Isn't this what the /MT flag should take care of?
I even tried to install the redistributable, but no luck. I'm still stuck with the error.
Another thing I tried was placing a MSVCP140.dll I downloaded in the folder, but that way my program is simply crashing on startup. I suspect that the MSCVP140.dll version is not the expected one, so I'm not relying on the validity of this test.
Any ideas?
Try to open your exe with depends.exe and find the dependancies in the machine it crashes. Probably the MSVCP140 might have other dependancies. Copy all dependancy dlls into same folder and give a try.
Someone please punch me for being this stupid... I was compiling on x86 instead of x64 all the time. No surprise the dlls didn't work.
Thanks for the help nevertheless. At least you got me on track to take a closer look at my dlls.
What am I doing wrong?
1. I write some code in Qt Creator, it works.
2. I save all, copy the folder with all the files in it to another location for safekeeping.
3. Then I write more code. This additional code doesn't work and I've gone too far to undo it.
4. So I close Qt, delete that folder, move the earlier one back to where it was originally, and load the older version.
But Qt still gives me the same errors that the newer code gave me, and won't run. It seems to remember this newer (bad) code even though it no longer appears anywhere in Qt - and the problem persists over computer reboot. I feel I'm missing something very obvious, but Mr Google can't help at all.
Try Build->Rebuild all. Your IDE is probably caching some of the previous results for performance reasons. I had the problem once using Qt Creator, and it solved it for me.
Delete the build folder. All that the build system knows about is the built files being newer than your now even older sources*. So a build won't succeed since plenty of intermediate files are wrong.
By the way, you really should be using version control, not moving folder around. I suggest git via smartgit, but that's just my personal preference. It's effortless.
* A build system could remember the absolute timestamps of the source used in the build and rebuild if they change, not only if the sources are newer than the results.
I have a helper DLL that I'm using for a long time without any change in its signature and I copy it to system32 in order to use it in all my products, now I add a function to its export list and compile it, everything looks OK and I have a new DLL that contain specified function. My problem is when I copy it into system32 specified function is missing, it looks like somehow it will be copied from a cache and some old version of it will be loaded, so programs that depend on new function will be failed! does anyone know what is the problem?
Most likely you have a 64 bit system. You copy the file to the 64 bit system directory, system32. But, because of the file system redirector, your 32 bit application loads it from the 32 bit system directory, SysWOW64.
Solve the problem by copying to SysWOW64.
You probably know this, but I feel compelled to say it anyway. The system directory belongs to the system and you should not be writing to it.
Use this to command to clear the dll cache. This has been tested on Win XP and Win 7.
sfc /purgecache
Please note that you need to be an admin to run this command or "Run as administrator". Not a 100% sure if this will fix your problem.
I'm using boost for several C++ projects. I recently made a upgrade (1.33.1 to 1.36, soon to 1.37), since then I cannot run any debug-builds anymore.
To be sure that no other project issues remain, I've created a minimum test-project, which only includes boost.thread, and uses it to start one method. The release build can be started, the debug build cannot, although the Dependency Walker shows that all required libraries are found (this also means that the required MS Debug CRT is found in the SxS directory).
On startup I only get:
Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002).
Klicken Sie auf "OK", um die Anwendung zu beenden.
Which means nothing more than "failed to initialize app". An internet research primarily lead to an MS Office installation problem, which recommends to perform a repair of WinXP.
So, beside the repair setup (which I think will not help as I'm talking about debug-dll issues), any ideas?
Ah, before I forget: Absolutely the same source-code leads to no errors on the build-machine (i.e., DLLs can be registered, means executed). So it's obviously an installation problem, but as the DLLs are there, and dependency-walker finds it, what else have I forgotten?
(edit) Well, I have not yet resolved my problem, but thanks to deemok I'm a step further. For the sake of reducing misunderstandings I give some clarifications below:
The program fails to run on the developer-machine
I am working with an installed VS2005 (it's a VC++8 project)
I used the boost-setup from BoostPro, compiled all possible build-versions, and I double-checked that they are there (otherwise I'd already get linker-errors during build).
and I double-checked any corner of include/lib/bin configuration I can think of -- as boost uses auto-linking on windows, with a special naming convention, the build or start-up would have failed, with a much more comprehensible error-message.
I cannot use static linking, as boost.thread requires dynamic linking for DLL projects (I maybe could mess around here, but as this problem seems to happen only on my machine, I do not want to mess with this, as I'm sure the boost-guys had a reason to place that check in there in the first place)
As I wrote, I checked with Dependency Walker, and it says everything is just fine.
Currently it seems to be an error in the boost-dll (maybe incorrect Manifest), will check that.
It's a Side-by-Side (SxS) issue – simply copying the DLLs is not enough anymore.
Regarding your specific problem concerning the Debug build, see: Running vc2008 debug builds on non-dev machines
Short answer:
You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together).
So, you'll need to install Visual Studio there.
However, if you still want to try without taking that path, you could read puetzk's answer in its entirety.
Or, you could try to link everything statically.
So you are using the pre-built libraries from BoostPro? If so, your environment might somehow be slightly different to the one they were built in (TR1 feature pack or not, etc). Perhaps best to try building Boost yourself in your specific environment.
This might turn out to have nothing to do with SxS. I suggest checking the Event Log for SxS error messages and using dependency walker to check for most probable DLL dependency issue, or one of the DLLs is returning FALSE from its DllMain (for whatever reason).
Also, enabling loader snaps:
gflags -i yourapp.exe +sls
might shed extra light when run under debugger (or dependency walker for that matter).
Note: gflags is part of Windows debugging tools.
Get yourself the dependency walker. Open your application exe in it. It will show you all the dlls that your application needs but can't load/access.
If that's not enough, you can also profile your app with the dependency walker, which will give you a lot of output to find out where the problem is.
[edit]
since you only have problems with the debug build:
make sure that when you upgraded boost, you also rebuilt not just the release binaries but also the debug binaries of boost. And of course, make sure that the debug build was built with the same version of VisualStudio than you're using now.
And make sure that the include paths (tools->options->projects and solutions->VC++ directories) are correct: the paths to the latest boost version must be there, not maybe to an older version.