I'm experiencing some troubles with AdaGIDE compiler and its libraries. I installed GNAT 2013 and AdaGIDE 7.45 on Windows XP. When I'm trying to compile any code that requires win32 (eg. with win32.winnt;) AdaGIDE's console says file "win32.ads" not found.
I searched the web and I found this, followed the instructions, installed the win32 package, ran setpath.bat, I even tried copying libraries into every GNAT folder I found - but nothing works. When I copy win32.ads to the folder with my program it requires more libraries so I guess copying all of them into my program directory wouldn't be a very good idea either.
Does anyone know how to deal with this problem?
-- Edit --
I had a little chat with the creator of AdaGIDE and all I had to do was to set Compiler Options in Tools -> Project setting in current directory to:
-Ic:\GNAT\2012\include\win32ada -Ic:\gnat\2012\lib\win32ada\static
c:\GNAT\2012\include\win32ada is where I installed Win32Ada, you also have to make sure that in \static\ there is a file named libwin32ada.a.
Unfortunately it has to be repeated for every new project.
As I write, libre.adacore.com is only showing the 2012 (and 2011!) releases. I expect the 2013 release will be back in a day or so.
Looking at the 2012 release for x86-windows, I see the eleventh entry on the list is "Win32Ada 2012". I think the 2013 version of that is what you need.
You might be able to install the 2012 version of Win32Ada into your 2013 GNAT installation ... worth a try if you can't wait!
In any case, Win32Ada is provided in a way that expects you to use GNAT Project (.gpr) files. It comes with examples: if you look in C:\GNAT\2012\share\examples\win32ada, you'll find various example projects; I tried connect, double-clicked on connect.gpr, it fired up GPS, I said Build>Project>Build All and it built connect.exe.
Related
When attempting to build my Qt project with MSVC2015 64bit for Windows 10, I get this error:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um\Ole2.h:37: error: C1083: Cannot open include file: 'objbase.h': No such file or directory
...
NMAKE:-1: error: U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64\cl.EXE"' : return code '0x2'
NMAKE:-1: error: U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64\nmake.exe"' : return code '0x2'
-- when nmake is invoked during the build process.
This exact same error also occurs for the example project "addressbook".
It appears to be some kind of toolchain issue, but I can compile a Qt Widget project in Microsoft Visual Studio 2022 if I point VS at my Qt installation.
I'm not sure what I need to do from here, since I already tried a reinstall of Qt. I have seen that putting things in Program Files is generally a bad idea, but that doesn't seem to be the issue in this specific case.
It appears to be part of the Windows SDK, if Google leads me right. However, I did not have to download the Windows SDK separately in order to compile my project and run it successfully before. (For context, the project's been developed for a few months and this problem only emerged a week or so ago).
My QT Installation:
Kit: Desktop Qt 5.15.2 MSVC2015 64bit
Version: Qt 5.15.2 MSVC2015 64bit
Compiler: Microsoft Visual C++ Compiler 17.3.32811.315 (amd64)
Things That Have Happened Before My Build Attempt:
I recently reinstalled Qt 5.15.2 in an effort to resolve a similar missing file issue.
The company's recently had issues with Microsoft Intune deleting applications. Maybe it hit the Windows SDK too.
Attempts at Solving the Issue
Reinstallation of Qt 5.15.2
Expected: My project building without errors. Result: This error.
Search of file system for objbase.h
Expected: Finding the file. Result: I did not find the file.
I'm newish at Qt, so I didn't want to try anything more esoteric lest I made things worse than before.
Update: MinGW 64 bit works for the example Qt projects, but I'd still like to use MSVC2015 if possible. It doesn't work for my project because I use some MSVC specific pre-processor flags in my source.
Update 2: I attempted to re-download MSVC 2015 from Visual Studio's website, using their Build Tools installer. While the installation successfully finished, I got no change from before -- it still can't find that "objbase.h" file. It's supposed to be in the Windows Kits directory under Include//um , I think.
It appears that, in my case, the objbase.h file was deleted due to the issue with Windows Defender deleting random files. I was able to reinstall the version of Windows SDK that was using and this fixed the issue for me.
I figured it out. I'm posting the solution here for others.
My issue was that, for reasons that are unclear to me, VS Studio Build Tools would not actually remove the SDK in question if I unchecked its box in the Modify screen. You can tell if this is happening by checking the disk size difference of the upcoming installation in the lower right of the screen -- if it won't remove the SDK, that size will be +0 bytes (assuming you don't check or uncheck any other box).
In order to properly reinstall the SDK version, I had to go to "Add or remove programs" and find the SDK there, uninstall it, restart my computer just for safety, and then go to VS Build Tools and install that SDK version. I had to do a "fake" uninstall with VS Build Tools (basically, uncheck the now-deleted SDK and click "Modify", allowing it to do the installation and download steps) before I could actually install the SDK again.
This is such a noddy question, but I'm struggling to particularly install libadalang which (to avoid X-Y problem) came from me having a working Gnatstudio, installing ada webserver, then I couldn't start Gnatstudio as it required libadalang.so. So I tried to install libadalang and
am currently getting failures of the form
libadalang-iterators-extensions.ads:29:29: file "langkit_support-symbols-precomputed.ads" not found
So I've spammed my /opt/GNAT/2020 with installing langkit everywhere that looks likely.
./lib/langkit_support
./lib/lib/langkit_support
./lib/include/langkit_support
./include/langkit_support
And still the installer for libadalang doesn't work.
Clearly something going on with paths here that I'm not getting. Can anyone provide any information on how paths are supposed to work as I need to install a number of other ada and SPARK-ada libraries from github and I want to do it correctly.
I think, the simplest way to restore GNAT Studio is to delete everything and reinstall. The GNAT Studio has its-own copy of libadalang/langkit. Look for
<install-path>/lib/gnatstudio/libadalang.so
<install-path>/lib/gnatstudio/liblangkit_support.so
When you install a developer version of libadalang you will get another copy of these files. They could have a different version.
I would suggest you to install GNAT Studio into a dedicated directory and make sure you launch it with a shell script from the bin (bin/gnatstudio). This way it shouldn't be affected by any other installed libraries.
Installing AWS shouldn't break GNAT Studio installation. If you know how to reproduce, please report to AdaCore.
Im following this guide: https://www.azerothcore.org/wiki/Installation
I am trying to compile build 6a95e61 with no additional modules under win64 and get 439 identical errors. They point to different files after like half a minute when selecting build/build solution in Visual Studio:
C2429 attribute 'nodiscard' requires compiler flag '/std:c++17' (compiling source file C:\Azerothcore\azerothcore\src\server\shared\DataStores\DBCDatabaseLoader.cpp) shared c:\azerothcore\azerothcore\src\common\datastores\dbcfileloader.h 38
A full wipe and starting over from git-bash yields the same results, so i guess im making mistakes in the process, any suggestion is appreciated.
Big thanks to the guys on azerothcore discord!
Steps which solved it for me:
Uninstalling Visual Studio 2017 and cMake 3.8.2
Installing Visual Studio 2019 with all dependancies in "Desktop Development with C++" and
Installing cMake 3.19.2
re-Built with cMake (as in the official guide)
Build/Build Solution in Visual Studio (as in the official guide)
First some background. At the end of 2012 we migrated our vs2008 solution to vs2010 but we still target .NET 3.5. (I know nothing but the latest and greatest here!)
We hadn't had any issues with this setup until a few weeks ago when people started getting these errors:
"foo.csproj" (Rebuild target) (16:5) ->
C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The interesting thing is that if you look at the project file it references v10 which makes sense because we don't use Visual Studio 2012.
This error hit several of us at once and even on older code branches that haven't changed in months.
I suspect some update got pushed onto our machines that confused things but I don't know what to do about it.
The short term solution has been to install VS 2012 and not use it but I'm hoping for something a little cleaner than that.
I ran into the same issue with Visual Studio 2013. It turns out that I was using the old version of MSBuild--the one that ships with the .NET Framework--from the command line. Microsoft is now releasing MSBuild as part of Visual Studio itself and also as a separate installer (http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx).
The solution was to use the new version of MSBuild.exe located in C:\Program Files (x86)\MSBuild\12.0\Bin. Once I did that, all the targets errors disappeared.
EDIT 1
As mentioned in the comments, each new version of MSBuild brings with it a new directory. For Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.
EDIT 2
As mentioned in the comments, for Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.
If you have a build server that does not have VS2012 installed, you can fix this by
a) installing the MSBuild.Microsoft.VisualStudio.Web.targets package to your solution, and
b) replacing this line in the .csproj file:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
With this line pointing to the nuget package
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
EDIT
As #joedragons points out the version in the updated line should match the nuget package version, i.e. replace targets.11.0.2.1 with targets.x.x.x.x for the current version.
A simple solution to this problem:
Go to the following path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio
You will see the latest version V10.0, v11.0, v12.0 depending on your Visual Studio 2010, 2012 or 2013 install.
Copy WebApplications folder from either of latest version directory and paste to other.
Your issues should be resolved.
I've found that installing the free Visual Studio 2012 Shell (Isolated) installs the WebApplications v11 MSBuild files. Lighter than a full install of Visual Studio 2012 and no licensing concerns.
Wow. We just saw the same thing happen on our build machine. We use VS2010 and target .NET 4.0. Our project files explicitly import the v10.0 version of these targets. With no changes to the code, yesterday the build was fine and today it's failing with a complaint about a missing v11.0 version. The .NET Framework 4.5.1 got installed/updated last night on this build machine as an automatic update. We're going to force v10.0 with the parameter (or env. variable), but this certainly took us by surprise...
UPDATE: What's even more weird, is that it seems to be the case that today's version of msbuild seems to be using the first line of the sln file to determine which VisualStudioVersion to use by default, whereas yesterday's version did not:
Format Version 12.00
We tested manually changing this to 11.00 and the build started working again.
In our case, even though we're targeting and building everything for 2010/4.0, some devs have been getting ready for VS2012 (since MS claimed that the project files are compatible), and this particular solution was last saved (months ago) in VS2012. Before today, that wasn't causing a problem.
I had the same issue. Fixed by going through above listed solutions. The issue is caused because appropriate version of Visual Studio Tools (BuildTools) is not available on the Build server. As rightly pointed above, this can be resolved by installing BuildTools but is not the option in my case.
Here is another alternative - use Nuget
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3
Identify the start up project and Install the web.targets based on the version of Visual studio being used.
The following files will be modified which includes the required changes
In packages.config:
<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />
In .csproj:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />
Hope this helps!!! Good Luck,
Cheers,
Hack, but solved it by copying:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications*.*
to
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications*.*
I got this error in the end of November without making any changes to either the configuration of my TeamCity installation or MSBuild installation or the source code. On my build server Visual Studio isn't even installed, and the change from VS2010 to VS2012 was made in the end of August without any problems at the time.
My MSBuild version is 4.0.30319.18408, my build server is a Windows Server 2008 R2 SP1 with TeamCity v6.5.3.
I solved the issued by simply copying the v11-folder from another build server which was unaffected.
My guess is that this could have happened in two ways:
Something was updated which triggered a deletion of the v11-folder. Could it be a Windows Update to .NET or something?
Something was updated which changed my TeamCity/MSBuild configuration from using v10 to v11 and the builds stop working as the v11 never existed.
I've got a update to .NET Framework 4.5.1 on December 3rd, could that be the reason?
Brgds
Jonas
I've recently got stuck with the same problem. And my conclusion is that every version of VS (v10, v11, v12) changes path of build variable, like MSBuildBinPath.
So specifying exact version of VS isn't a hack, because you might not even have appropriate version of files installed. So intead you'd better specify a parameter and use targets that exist on you machine.
In some rare cases you might need to install specific version of VS and Web Deploy package. In my case just version was enough to solve problem.
You can add the VisualStudioVersion property like this:
<ItemGroup>
<ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
<Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
</ProjectToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)" Targets="Rebuild"/>
As I was searching how to solve this one, almost everyone recommended either to copy the missing MSBUILD folder or install some SDK of some version.
Luckily, I've found this awesomely helpful post by Donovan Brown :
http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!
In a nutshell, the idea is to configure the VisualStudio version your build should use in your Build Definition:
Right Click -> "Edit Build Definition..."
Go to "Procss" -> "3. Advanced"
and set "MSBuild Arguments" with
/p:VisualStudioVersion=12.0
I'm trying to install Qt-4.6.0-wince on XP and Vista. I read the instructions and follow it to install.
However, I can't install it successfully due to some fatal errors on all of the two machines. I think the problem is that qconfig.[h cpp] files are not created automatically during the configuration.
I already report about this problem, so you can see the more information here. However, it is still remained as unresolved.
Anybody here who has been installed it successfully?
#KernelJ I believe the original poster is using the correct install distro - the final product will be cross compiled from Win32 to WinCE; as is pointed out in the Qt for Windows CE Requirements.
#Brian, Unfortunately, I can't answer your original question - I have had unrelated trouble with the WinCE distribution myself and am working the issues now. However, I can provide some help: I was able to get the Qt Everywhere 4.6 to cross compile on my Win32 (XP) host for WinCE. I used the commercial version, but here is a link to the Open Source Qt Everywhere 4.6 package. As is pointed out in the nokia instructions, make sure to use the Visual Studio command prompt, get your environment variables ironed out, create a custom mkspec (if you have to), and keep a close eye during the configuration for any warnings.
Good luck.
Qt-4.6.0-wince, as is implied in the name and said explictly on the page you linked, is for Windows CE, NOT for Windows XP and Vista!!!
Nokia have released a nice software development kit for Qt which you can download here. It is very impressive and powerful!
I got things running as compilable (and running on emulator) with VS 2008, so your milage may vary:
Make sure the PATH variable points to \bin
Open a command prompt (using the Visual Studio Command Prompt)
Run the vcvars32.bat file (in C:\Program Files\Microsoft Visual Studio 9\VC\bin) folder
Cd into the qt folder
Run this: configure -no-sql-sqlite -no-qt3support -platform win32-msvc2008 –xplatform wincewm50pocket-msvc2008 -no-phonon -no-phonon-backend -no-webkit (building for WINCE 5.0, and all the '-no-...' makes it build faster, removing stuff we don’t want)
The setccepaths script provided sometimes doesn’t work. I used checksdk.exe –script temp_script.bat (It creates a script, the default is for Pocket PC SDK 5)
Run that script you just created (the temp_script.bat thing. It sets up environment variables.
Run nmake
*whew*
and good luck.