So I have a decent understanding of c++ and have been following a course on udemy to better understand unreal itself. I've had it installed about a week working great but it recently decided to take for ever to compile. Normally it takes like a minute at most and rarely that but now its taking up to a like 30 mins. I deleted and made it remake the binary's same issue. I've tried googling it i can't seem to find anything to help. This is the message output.
Total execution time: 1489.19 seconds
Building BullCowGameEditor...
Using Visual Studio 2019 14.25.28612 toolchain (C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610) and Windows 10.0.18362.0 SDK (C:\Program Files (x86)\Windows Kits\10).
[Upgrade]
[Upgrade] Using backward-compatible build settings. The latest version of UE4 sets the following values by default, which may require code changes:
[Upgrade] bLegacyPublicIncludePaths = false => Omits subfolders from public include paths to reduce compiler command line length. (Previously: true).
[Upgrade] ShadowVariableWarningLevel = WarningLevel.Error => Treats shadowed variable warnings as errors. (Previously: WarningLevel.Warning).
[Upgrade] PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs => Set in build.cs files to enables IWYU-style PCH model. See https://docs.unrealengine.com/en-US/Programming/BuildTools/UnrealBuildTool/IWYU/index.html. (Previously: PCHUsageMode.UseSharedPCHs).
[Upgrade] Suppress this message by setting 'DefaultBuildSettings = BuildSettingsVersion.V2;' in BullCowGameEditor.Target.cs, and explicitly overriding settings that differ from the new defaults.
[Upgrade]
Building 4 actions with 24 processes...
[1/4] BullCowCartridge.cpp
Creating library C:\Users\Jacob Krumholz\Desktop\Unreal\BullCowGame-starter-kit\Intermediate\Build\Win64\UE4Editor\Development\BullCowGame\UE4Editor-BullCowGame-3564.suppressed.lib and object C:\Users\Jacob Krumholz\Desktop\Unreal\BullCowGame-starter-kit\Intermediate\Build\Win64\UE4Editor\Development\BullCowGame\UE4Editor-BullCowGame-3564.suppressed.exp
[2/4] UE4Editor-BullCowGame-3564.lib
Creating library C:\Users\Jacob Krumholz\Desktop\Unreal\BullCowGame-starter-kit\Intermediate\Build\Win64\UE4Editor\Development\BullCowGame\UE4Editor-BullCowGame-3564.lib and object C:\Users\Jacob Krumholz\Desktop\Unreal\BullCowGame-starter-kit\Intermediate\Build\Win64\UE4Editor\Development\BullCowGame\UE4Editor-BullCowGame-3564.exp
[3/4] UE4Editor-BullCowGame-3564.dll
[4/4] BullCowGameEditor.target
Total time in Parallel executor: 1488.05 seconds
I've restarted VS, UE4, and windows just in case that was the issue. I could reinstall it if the issue won't go away but that would be a pain. I'm on windows 10 and UE4.24.3.
Related
I'm having a weird error after updating Visual Studio 2019 Community from v16.4.5 to 16.5. Even a fresh install of the engine will no longer build. I'm getting the errors listed below. The build doesn't fail until the end of compiling all modules:
Error C4800 Implicit conversion from 'ADODB::_Recordset *const ' to bool. Possible information loss UE4 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\INCLUDE\comip.h 311
Error C4800 Implicit conversion from 'ADODB::_Connection *const ' to bool. Possible information loss UE4 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\INCLUDE\comip.h 311
Error MSB3075 The command "..\..\Build\BatchFiles\Build.bat -Target="UE4Editor Win64 Development" -Target="ShaderCompileWorker Win64 Development -Quiet" -WaitMutex -FromMsBuild" exited with code 5. Please verify that you have sufficient rights to run this command. UE4 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets 44
I have not changed or updated anything on the Unreal Engine-side of the code. This error occurs during a build of UE4.sln, sourced from Epic's github repo. The build doesn't fail until all modules are built (it fails at the end of the build).
Seeing as Microsoft doesn't have archives of installers for VS Community, only Enterprise and Pro, I'm kind of suddenly stuck here because I can't just uninstall 16.5 and reinstall 16.4.5 (which is the last working version I was on before the update).
I heard sometimes setting "treat warnings as errors" to false can help, but I don't see a way to do that in Visual Studio.
Any insight into this would be helpful, Thanks!
So, turns out something changed on VS2019's side in the update from 16.4.5 to 16.5, but the fix for UE4 can be found in this commit on the 4.25 branch. Confirmed that this solved my problem!
First Make a backup of your whole project (just copy it to somewhere else).
Afterwards delete the following folders in the project directory:-
.vs
Intermediate
Saved
you just need to delete the .vs folder to solve the problem. The rest are just for a quick refresh of your project.
Next open Unreal Engine 4, then under File tab click on Refresh Visual Studio Project. On completion try to compile again. This should solve your problem.
For those who facing the same problem, here is the solution.
Step 1:
open the file ADOSupport.cpp on [YourEngineSourceDir]\Engine\Plugins\Runtime\Database\ADOSupport\Source\ADOSupport\Private
Step 2:
go to line 255 and modify it
from if(ADORecordSet && (ADORecordSet->State & ADODB::adStateOpen))
to if(ADORecordSet != nullptr && (ADORecordSet->State & ADODB::adStateOpen))
Step 3:
got to line 328 and modify it from if( DataBaseConnection && (DataBaseConnection->State & ADODB::adStateOpen)) to if( DataBaseConnection != nullptr && (DataBaseConnection->State & ADODB::adStateOpen))
Step 4: Build the solution and enjoy!
You should add the new line of code, like on the video tutorial:
Arguments.Add("/wd4800"); // 4800: Implicit conversion from 'type' to bool. Possible information
https://youtu.be/KXIv4y51fyw
That fix me that issue.
I had the same issue, and this solved it:
File Path
YOURENGINEPASS\Engine\Source\Programs\UnrealBuildTool\Platform\Windows
File to change
VCToolChain.cs
After line 456 add the following line:
Arguments.Add("/wd4800"); // 4800: Implicit conversion from 'type' to bool. Possible information
I saw many many people ask this question and apparently there is no absolute answer to this question.
this happened for me when I uninstall my visual studio 2015 cause unreal 4.18 no matter I do use VS 2015 and I want to use 2017 and I saw some people solve this problem with uninstalling VS 2015.
when I uninstall VS 2015 receive this error when I want to create a new C++ project:
The project could not be compiled. Would you like to open it in Visual Studio?
Running f:/Program Files/Epic Games/UE_4.19/Engine/Binaries/DotNET/UnrealBuildTool.exe MyProject451 Development Win64 -project="F:/c++ New/New folder/MyProject451/MyProject451.uproject" -editorrecompile -progress -NoHotReloadFromIDE
Performing full C++ include scan (building a new target)
Creating makefile for MyProject451 (no existing makefile)
#progress push 5%
Parsing headers for MyProject451Editor
Running UnrealHeaderTool "F:\c++ New\New folder\MyProject451\MyProject451.uproject" "F:\c++ New\New folder\MyProject451\Intermediate\Build\Win64\MyProject451Editor\Development\MyProject451Editor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -installed
Reflection code generated for MyProject451Editor in 7.2801937 seconds
#progress pop
Performing 9 actions (4 in parallel)
[2/9] Resource ModuleVersionResource.rc.inl
[3/9] Resource PCLaunch.rc
SharedPCH.Engine.cpp
MyProject451GameModeBase.cpp
MyProject451.init.gen.cpp
MyProject451.cpp
MyProject451GameModeBase.gen.cpp
[8/9] Link UE4Editor-MyProject451.dll
[9/9] Link UE4Editor-MyProject451.lib
LINK : fatal error LNK1181: cannot open input file 'ws2_32.lib'
Creating library F:\c++ New\New folder\MyProject451\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-MyProject451.lib and object F:\c++ New\New folder\MyProject451\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-MyProject451.exp
ERROR: UBT ERROR: Failed to produce item: F:\c++ New\New folder\MyProject451\Binaries\Win64\UE4Editor-MyProject451.dll
Total build time: 34.18 seconds (Local executor: 0.00 seconds)
image of error (i copy notes in above as you can see ):enter image description here
many peoples mention its relate to Windows SDK and there is windows SDK in installing if I add more let me know.
enter image description here
I thought if I install unreal 4.19 its maybe get fixed but it didn't.
it seens ue4 genrate C++ files for VS 2015.
enter image description here
I hope there is anyone known how to solve this problem and guide me how.
I fix it with downloading this cleaner form this link https://github.com/Microsoft/VisualStudioUninstaller/releases .
after that UE4 when you want to create new project sends a message and it says you don't have VS2017 don't panic just download the installer and modify it after that it downloading about 350 mg and after that, everything will get fixed.
for more info :
https://answers.unrealengine.com/questions/597939/new-c-project-fails-to-compile-using-ue-415-and-vs.html
I'm following this guide on building V8 but I am hitting some issues on the compilation step. I am running Windows 10 x64. I am trying to compile with options to embed the engine also.
Running the following command:
ninja -C out.gn/x64.release
Gives me this error:
ninja: Entering directory `out.gn/x64.release'
[1/471] LINK mksnapshot.exe mksnapshot.exe.pdb
FAILED: mksnapshot.exe mksnapshot.exe.pdb
C:/Workspace/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb #./mksnapshot.exe.rsp
LINK : fatal error LNK1181: cannot open input file 'comdlg32.lib'
ninja: build stopped: subcommand failed.
Now I believe I have narrowed down the error to looking for the .lib files in the wrong directory. I have (had) multiple versions installed, so there were multiple folders in my Windows Kit install.
Windows Kits/10/Lib/10.0.16299.0
Windows Kits/10/Lib/10.0.15xxx.0
If I dragged and dropped the comdlg32.lib file from 10.0.16299.0 into the 10.0.15xxx.0 directory then the error changed to a LNK1181 error with a different input file. I did this a few times but I was unsure if this was going to cause issues with different versions and there was probably going to be a lot.
I uninstalled the 10.0.15xxx.0 version which left behind the folder I mentioned, so I removed that and after doing so I have started getting the LNK1181 error with a different input file (advapi32.lib I assume the very first file it can't find). This is how I came to the conclusion about the path being incorrect.
So I have tried a few things to change the path (I hoped just uninstalling the old version would fix it) such as:
Uninstalling the old version.
Going through registry entries to see if I can find an install path or something using that path, which I didn't. I did notice that there was still installation and data in the registry for the 10.0.15xxx.0 install, I might try deleting that from the registry directly as a last resort?
I have tried to explicitly set the path by setting <TargetUniversalCRTVersion>10.0.16299.0</TargetUniversalCRTVersion> in this file: C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\uCRT.props
I have never used Ninja before so I tried looking for a way to set some kind of lib-path in the command but couldn't really find anything.
I looked through the python scripts being executed to try and locate something to do with the libs path but couldn't see anything.
I would be grateful for any help and suggestions. Thanks.
You can try to compile v8 using Visual Studio as explained here: https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#using-the-visual-studio-ide
By running the following commands:
$ gn gen --ide=vs out.gn/x64.release
$ cd out.gn/x64.release
$ msbuild all.sln
You can see a full example here: https://github.com/phpv8/v8js/issues/272#issuecomment-262848754
Apparently this method is not officially supported anymore, but I had the same problem as you have and this solved the issue for me.
Note that after this I had another issue, the unit tests failed to be compiled due to a linking error, but I had the necessary libraries to use v8. So there may be deeper problem that is causing all of this that I'm missing.
Edit:
Also, you could try to set the following parameters with gn args:
visual_studio_path = "..."
visual_studio_version = "2017"
wdk_path = "..."
windows_sdk_path = "C:\Program Files (x86)\Windows Kits\10"
To set those parameters, do:
gn args out.gn/x64.release
This will open a text editor where you can write the extra parameters you are interested in.
To see the full list of parameters you can specify:
gn args --list out.gn/x64.release
I was following this guide https://medium.com/dailyjs/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4 and also ran into the error
LINK1181: cannot open input file 'advapi32.lib'
I'm pretty sure it was because I had the wrong versions of the Windows 10 SDK. Similar to you I had versions:
Windows Kits/10/Lib/10.0.10240.0
Windows Kits/10/Lib/10.0.16299.0
But according to https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows (Which I think is relevant) you need version 10.0.15063.0
After installing version 10.0.15063.0 (with the visual studio installer) to
Windows Kits/10/Lib/10.0.15063.0
I was able to continue with the build.
I am using VS2010 (pro) and VS2015 Express.
Recently (probably as a result of installing some other software) all my 32 bit builds started failing with
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe" #C:\Users....rsp". The handle is invalid.
(64 bit builds continue to work)
The problem appears to be MSBuild invoking the 64 bit version of Tracker.
Google tells me that others have had the opposite problem in that 64 bit builds get the same error, whilst 32 bit builds succeed
Looking at procmon I find that MSBUILD
(1) opens Registry Key
HKLM\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full
which has an InstallPath value of
C:\Windows\Microsoft.NET\Framework\v4.0.30319\
(2) tries to open C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Tracker.exe which does not exist
(3) opens registryKey
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86
(which does not exist, although
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.1A\WinSDK-NetFx40Tools-x86
does)
(4)opens file
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\Tracker.exe
Which generates the error above
I'm at a loss to explain the presence of the "x64", especially as MSBuild appears to be looking for a file path in a registry key that ends in -86
From http://community.sharpdevelop.net/forums/p/11439/31258.aspx there is a wordaround to disable tracker by adding
"False" to a property group in the .vcxproj file.
But this entails changing many such files
Any advice welcome
I've been able to solve the same issue by making sure _IsNativeEnvironment environment variable is set to false.
I am currently trying to upgrade our c++ mfc solution from visual studio 2010 to a visual studio 2013 solution. When i try to build it i get the error MSB4018 The "ResolveComReference" task failed unexpectedly. I enabled fusion logging and this is what it tells me:
=== Pre-bind state information ===
LOG: DisplayName = System
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: System | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Build.Tasks.v12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. ===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.EXE.
I understand that msbuild has been moved, but i dont understand why it is trying to find System.dll in the msbuild path, how can i make it look for it in its proper location?
Edit:
I have now also tried upgrading to visual studio 2012 which worked without bigger problems and I did not run into the same problem. However i noticed that when running devenv /upgrade (with vs2013) it seems to completely change everything under vc++ directories (it stayed unchanged when upgrading to vs2012). Could this have something to do with this issue?
Edit2:
Tried to build the project in vs2013 after upgrading it to 2012 (without running devenv /upgrade), this also didnt work so I guess the problem is not related to that...
After enabling diagonostic build output i found that it was 3 broken COM references in the project that where failing to load. Removing these references solved the building issue. These where only showing up as warnings in vs2010 but resulted in MSB4018 in vs 2013 for some reason.
This is your problem:
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
Fix the base folder in your build system if you really need it to point to another filder. However it would probably be better to redo you build system targeting 2013 instead of patching the 2010 version.