I have installed colmap via vcpkg and it's not showing up for me. It shows up on .\vcpkg list but not on Visual Studio 2019.
All of colmap's dependencies are showing up when I do #include "" and they also show up on #include <> along with many other libs, but no colmap can be found.
What can I do? Let me knowm if there's any other info I can give, I'm fairly new to C++ and Visual Studio, so there's only so much I know is important.
I was finally able to include colmap. I had not payed attention to the debugger version I was using. It was set to x86 and my colmap was compiled at x64, so it would never show up on my VS2019!
Related
I have a fairly large project built using Qt 4.8.7.
Up until recently I have ben using Visual Studio 2010 for development and debuging (using the qt add-in).
I have upgraded to Visual Studio 2017 now and am not able to properly, for example, inspect the value of a QString (only partially, like the first letter of the string) anymore.
I tried installing the "new" qt tools thing without success.
Any advice on that topic?
Is this even possible with Qt 4.8.7 and VS2017 or do I have to upgrade the whole project to Qt 5 in order to properly debug?
A more detailed answer for people who will pass-by. You can download qt4.natvis from here, and add it to the system-wide Natvis directory (%VSINSTALLDIR%\Common7\Packages\Debugger\Visualizers).
I found a compatible .natvis file for Qt 4 on the net, directing VS17 to the file fixed my problem
I have installed the Visual Studio 2015 and created Win32 project with some code. I compiled it successfully, but I can't launch exe file, because I don't have some ucrtbased.dll...So how can I solve it?
Edit:
The English equivalent message is:
"The program can't start because ucrtbased.dll is missing from your computer. Try reinstalling the program to fix this problem. "
This problem is from VS 2015 silently failing to copy ucrtbased.dll (debug) and ucrtbase.dll (release) into the appropriate system folders during the installation of Visual Studio. (Or you did not select "Common Tools for Visual C++ 2015" during installation.) This is why reinstalling may help. However, reinstalling is an extreme measure... this can be fixed without a complete reinstall.
First, if you don't really care about the underlying problem and just want to get this one project working quickly, then here is a fast solution: just copy ucrtbased.dll from C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\ucrtbased.dll (for 32bit debug) into your application's \debug directory alongside the executable. Then it WILL be found and the error will go away. But, this will only work for this one project.
A more permanent solution is to get ucrtbased.dll and ucrtbase.dll into the correct system folders. Now we could start copying these files into \Windows\System32 and \SysWOW64, and it might fix the problem. However, this isn't the best solution. There was a reason this failed in the first place, and forcing the use of specific .dll's this way could cause major problems.
The best solution is to open up the control panel --> Programs and Features --> Microsoft Visual Studio 2015 --> Modify. Then uncheck "Visual C++ --> Common Tools for Visual C++ 2015". Click Next, then and click Update, and after a few minutes, Common Tools should be uninstalled. Then repeat, but this time install the Common Tools. Make sure anti-virus is disabled, no other tasks are open, etc. and it should work. This is the best way to ensure that these files are copied exactly where they should be.
Error Codes: Note that if the installer returns a cryptic error number such as -2147023293, you can convert this to hex using any of the free online decimal-to-hex converters. For this error it is 0xFFFFFFFF80070643 which, dropping the FF's and googling for "0x80070643", means `0x80070643 - Installation cache or ISO is corrupted'.
Why is ucrtbased.dll even needed?: Any DLL named "crt" is a "C-Run-Time" module or library. Microsoft explains them best. There are many variants of CRT today. They contain essential helper-code used by all Microsoft compiled executables, to "shim" or help your executable operate on the ever-growing number of OS versions and hardware. If the MSVC compiler is used, the relevant CRT DLL is linked automatically at compile-time. (If the DLL cannot be found at compile-time, then a linking error is generated.)
One way to not require the DLL, is to "statically-link" it to your project. This means that you essentially take the contents of ucrtbased.dll, and include it in your executable. Your file size will grow by approximately the size of ucrtbased.dll.
Incidentally, if you've ever run a MSVC program (usually from another individual, one of your old compiled programs from a previous OS version, or yours from a different machine) and it does not start, giving an error message of needing "Microsoft Visual C++ 20xx Redistributable" or "run-time" - then it means it can't find the needed *crt*.dll file. Installing that particular redistributable package (if known) will install the DLL, and allow the program to run... or at least get past that error and alert you of another missing DLL.
If you find yourself in this "DLL Hell" predicament, google "dependency walker" for an advanced tool to show which DLLs are still missing. This usually doesn't happen with professional software, simply because their (large, bundled) installers check for any missing dependent libraries (including CRT) and installs them first.
The problem was solved by reinstalling Visual Studio 2015.
rdtsc solution did not work for me.
Firstly, I use Visual Studio 2015 Express, for which installer "modify" query does not propose any "Common Tools for Visual C++ 2015" option you could uncheck.
Secondly, even after 2 uninstall/reinstall (many hours waiting for them to complete...), the problem still remains.
I finally fixed the issue by reinstalling the whole Windows SDK from a standalone installer (independently from Visual C++ 2015 install):
https://developer.microsoft.com/fr-fr/windows/downloads/windows-8-1-sdk
or
https://developer.microsoft.com/fr-fr/windows/downloads/windows-10-sdk
This fixed the issue for me.
An easy way to fix this issue is to do the following (click on images to zoom):
Make sure to close Visual Studio, then go to your Windows Start -> Control Panel -> Programs and Features. Now do this:
A Visual Studio window will open up. Here go on doing this:
Select the checkbox for Common Tools for Visual C++ 2015 and install the update.
The update may takes some time (~5-10 minutes). After Visual Studio was successfully updated, reopen your project and hit Ctrl + F5. Your project should now compile and run without any problems.
I would like to suggest additional solution to fix this issue. So, I recommend to reinstall/install the latest Windows SDK. In my case it has helped me to fix the issue when using Qt with MSVC compiler to debug a program.
I am not sure it will help but you can try this.This worked for me
Start -> Visual Studio Installer -> Repair
after this enable the Microsoft Symbols Server under
TOOLS->Options->Debugging->Symbols
This will automatically set all the issues.
You can refer this link as well
https://social.msdn.microsoft.com/Forums/vstudio/en-US/6aa917e5-a51c-4399-9712-4b9c5d65fabf/ucrtbasedpdb-not-loaded-using-visual-studio?forum=visualstudiogeneral
I'm a new guy in Cocos2d-X. I download the cocos2d-x-3.8.1.zip, the newest version in official website, http://www.cocos2d-x.org/.
Extract the zip, I successfully open and build /cocos2d-x-3.8.1/build/cocos2d-win32.sln with Visual Studio2015 community.
Then I try to open cocos2d-x-3.8.1/templates/cpp-template-default/proj.win32/HelloCpp.sln, but the VS2015 tell me there are errors when load solution.
I thought VS2015 is too new for Cocos2d-x-3.8.1, so I uninstalled the VS2015, install the Visual Studio 2013 community. But the same thing happen, build/cocos2d-win32.sln is successful, /templates/HelloCpp.sln is failed.
I follow some books, it tell me to set up a template Visual Studio template with VC++ for cocos2d-x, but I wonder why it's failed when I build the cpp template.
Is VS2013/2015 to new for cocos2d-x-3.8.1 ?
Is it a must to use Visual Studio 2012 ?
You don't just download and extract there is more to do then just that
you need to setup cocos2d-x environment variables first then run your projects
and here is a you-tube tutorial that shows you how to:
https://www.youtube.com/watch?v=B9ObAzm6rnQ&index=3&list=PLRtjMdoYXLf4od_bOKN3WjAPr7snPXzoe
after you do all the steps in the video just open cocos2d-win32.sln and run it and it will automatically builds(takes a minute or tow) then runs.
PS: VS 2013 or 2015 both should work ... i myself using cc2d 3.8 with VS2013update5 and it all works fine.
I've just attempted to use Firebreath and have followed their video tutorial for Windows and come across the error that says:
Check for working C compiler using Visual Studio 10 -- broken
And then says:
It fails with following output:
Change Dir:
And then lists the drive. This happens when running prep2010.cmd. I have found a post about it, but the forums won't let me log in and there is no answer. It's here: http://forum.firebreath.org/topic/274/?page=1#post-1117 and is exactly the same error, I believe. The last post talks about running prep2010 from inside the vs2010 command shell. What does that mean?
Has anyone else had this error or know how it is caused? I have no idea how to approach it.
Thankyou
I know this is really old.. but in case someone else has this problem, the solution for me was to install service pack 1 for visual studio 2010
As I said in the comment above, this is not "FireBreath" that is saying your compiler is broken; the prep command uses CMake to generate the project files, and it is from cmake that the error comes.
In your start menu where Visual Studio 2010 is there should be a "tools" or "utilities" subfolder and in there somewhere there is a "Visual Studio 2010 Command Prompt" link. That starts a command prompt with environment variables and path set up so that the vs2010 commands are all available. The error you're seeing is indicating that for whatever reason, CMake is unable to find visual studio 2010.
I don't know if using the vs2010 command prompt will help or not; it doesn't have any trouble finding vs2010 on any of my boxes. I can postulate that perhaps if you installed it to a nonstandard location, in a nonstandard way, or your registry got screwed up any of these things could potentially cause the issue that you are seeing. Also if you don't have vs2010 installed it would certainly cause this issue =]
I'd recommend first trying the vs2010 command prompt; if that doesn't work, you may have to try uninstalling and reinstalling vs2010. If that doesn't work, I'm out of ideas, and maybe someone who knows more about cmake will have a suggestion :-(
Service pack 1:
http://www.microsoft.com/en-us/download/details.aspx?id=23691
Configure cmake with generator: MSVC2010 x64
I also had MSCV 2010 x64 on windows 7 and installing service pack one also helped.
Also make sure that all your external dependancies are (x64) versions:
MSVC version:
http://visual-studio-2010.en.malavida.com/
Gl&HF
I'm trying to compile WebKit on Windows XP. I've followed to the letter the installation instructions for all the recommended development tools. The WebKit project suggests debugging using Visual-Studio 2005.
Whenever I open the WebKit project in VS2005 (express), however, VS always crashes shortly afterward. This is before I try to run any of the WebKit code, so I think the problem is with VS2005, and not with WebKit.
The error log says this:
Faulting application vcexpress.exe, version 8.0.50727.762, faulting
module msvcr80.dll, version 8.0.50727.6195, fault address 0x00008aa0.
So it looks like the problem is with msvcr80.dll.
I'm not very experienced with windows. Does anyone know how to investigate the cause of this crash and fix it?
Many, many thanks,
D
* UPDATE *
In the end I couldn't get VS2005 to stop crashing, so I switched to Visual Studio 2008 Express. WebKit.org doesn't give instructions for building with VS2008, but I found some on this blog. These mostly worked, though I had to make two small changes.
Currently, if no standard editions Visual Studio can be found (not 'Express'), the build scripts are hard-coded to use VS Express 2005. To use VS Express 2008 instead, I changed line 1419 of /Tools/Scripts/webkitdirs.pm from this:
$vsInstallDir = File::Spec->catdir($programFilesPath, "Microsoft Visual Studio 8");
to this:
$vsInstallDir = File::Spec->catdir($programFilesPath, "Microsoft Visual Studio 9.0");
(Carefully not to confuse the years of release --2005, 2008-- with the versions -- 8,9.0)
I also had to work around a bug related to error logging. In line 60 of /Tools/Scripts/print-vse-error-logs I changed "scm.find_checkout_root()" to the path to my source directory "C:/cygwin//Webkit/Source".
I hope this helps someone!
Do you have the lastest service pack installed on both XP and Visual Studio 2005? if not (How to obtain the latest Visual Studio 2005 service pack). If that doesn't fix it, trying doing the same thing with Visual Studio 2010 (SP1), for it may have been fixed since then and you could be running into known issues which have since been resolved.
HTH