>I believe you also did some work to share cache artifacts even when the absolute root path is different between machines?
Just quickly weighing in here, this is done via the -vfs option in UBT.
Julian
Will test the extra space after includes, thanks 
Hi Julian,
I’ll get you the patch and logs asap.
In the mean time, I can confirm that the link issue is present even without caching. However it only occurs on our plugins/games dlls, also related to our patch I guess!
[15/20] Link [x64] UnrealEditor-ALFEditor.dll
LINK : fatal error LNK1168: cannot open C:\dne\monorepo-preview\Game\TEST\Binaries\Win64\UnrealEditor-TESTEditor.dll for writing
Link [x64] UnrealEditor-TESTEditor.dll: Exited with error code 1168 . The build will fail.
Link [x64] UnrealEditor-TESTEditor.dll: WorkingDirectory C:\dne\monorepo-preview\UE\Engine\Source
Link [x64] UnrealEditor-TESTEditor.dll: C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\link.exe @“C:\dne\monorepo-preview\Game\TEST\Intermediate\Build\Win64\x64\UnrealEditor\Development\TESTEditor\UnrealEditor-TESTEditor.dll.rsp”
The .rsp for failing link steps specify the .dll file with full path:
/OUT:“C:\dne\monorepo-preview\Game\TEST\Binaries\Win64\UnrealEditor-TESTEditor.dll”
Hello Julian,
Yes, it does work without UBA, wether with the default parallel executor or with our internal FASTBuild executor.
I didn’t make it clear, but the patch I mentioned has been in use for several years now and we shipped multiple projects with it. We have plans to drop it in the future and rely on Unreal’s native ‘AdditionalDirectories’ feature.
Edit : see this question for example [Content removed]
Here’s the log from UBT after I `touch` a .cpp file, and do a standard build.
I’ve previously compiled all UBA projects in Debug from the Uba solution (afaik the build already places them in the correct folder).
You can see a linker error that can’t open the DLL. However the file exists.
I tried running UbaCli.exe under VS to debug what’s happening, and it also fails in the same way. My command line:
UbaCli.exe -workdir=C:\dne\monorepo-preview\UE\Engine\Source -cache=“192.168.3.127” local “C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\link.exe” @C:\dne\monorepo-preview\DNE\Plugins\Core\DNEAnimationCore\Intermediate\Build\Win64\x64\UnrealEditor\Development\DNEAnimationCoreRuntime\UnrealEditor-DNEAnimationCoreRuntime.dll.rsp
However, if I run the link step myself from a shell, it works.
So I’m thinking, but this is a wild guess, that Detour might have something to do with this? I’ve also noticed that we had several include directives with a trailing space in the filename, such as
include "SomeHeader.h "
that worked without anyone noticing for years, on msvc and clang-cl, but failed instantly under UBA with a “file not found” error.
I’ve also attached our patch, named DNEGameSupport. It’s quite pervasive, sorry about that.
I fixed the include directives already, they were not related to these link issues.
The patch should have been in my zip file, in the form of DNEGameSupport.diff, I’m adding it to this message anyway.
Hi Julian,
Thanks for taking the time.
It’s good to know that AdditionalPluginDirectories work correctly, it’s one more reason for us to migrate towards this. However to be clear we are _not_ using it yet, as our patch does kind of the same thing.
I’ve compiled all UBA project in debug from UBA.sln, and get the same error when running what you asked.
`PS C:\dne\monorepo-preview\UE\Engine\Binaries\Win64\UnrealBuildAccelerator\x64> ./UbaCli.exe -workdir=C:\dne\monorepo-preview\UE\Engine\Source -cache=“192.168.3.127” local “C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\link.exe” @C:\dne\monorepo-preview\DNE\Plugins\Core\DNEAnimationCore\Intermediate\Build\Win64\x64\UnrealEditor\Development\DNEAnimationCoreRuntime\UnrealEditor-DNEAnimationCoreRuntime.dll.rsp
UbaCli v5.5.4-Uba_v1.0.0-0 (DEBUG) (Rootdir: “C:\ProgramData\Epic\UbaCli”, StoreCapacity: 20Gb)
UbaServer - Created in DEBUG
---- Starting trace: Debug ----
UbaClient (0aada7a7-cca7-481f-bde8-b063340818b3) - Connected to server… (0x0000048B94070290)
UbaClient (0aada7a7-cca7-481f-bde8-b063340818b3) - Connected to 192.168.3.127:17157 (f269faa9-ec91-4ad1-948d-d0817cb91664)
UbaStorageServer - Database loaded from C:\ProgramData\Epic\UbaCli\cas\casdb (v32) in <1ms (contained 0 entries estimated to 0b)
UbaCacheClient - PATH WITHOUT ROOT: (inside CmdKey C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\link.exe at offset 0)
Running C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.38.33130\bin\Hostx64\x64\link.exe @C:\dne\monorepo-preview\DNE\Plugins\Core\DNEAnimationCore\Intermediate\Build\Win64\x64\UnrealEditor\Development\DNEAnimationCoreRuntime\UnrealEditor-DNEAnimationCoreRuntime.dll.rsp
LINK : fatal error LNK1168: cannot open C:\dne\monorepo-preview\DNE\Plugins\Core\DNEAnimationCore\Binaries\Win64\UnrealEditor-DNEAnimationCoreRuntime.dll for writing
Error exit code: 1168
UbaClient (0aada7a7-cca7-481f-bde8-b063340818b3) - Disconnected from server… (0x0000048B94070290) (0)`(had to run it from a VS Powershell prompt, otherwise linker fails because it’s not able to find mt.exe)
replying to avoid automatic closing
Hi Julian,
I won’t be able to pursue this for two weeks but I’ll be coming back at it. I hope we can avoid closing the ticket
Hi Julian,
Here’s what I did:
- checkout branch 5.6 from Unreal’s github (ue5-main fails in GitDependencies due to invalid compression)
- generate Uba.sln and compile it in Debug, copy the binaries to my test bed
- run Build.bat BlankProgram Development Win64
- the full build completes successfully
- touch BlankProgram.cpp to trigger a recompile
- run Build.bat BlankProgram Development Win64 -UbaLog
- the build fails with the infamous LINK : fatal error LNK1168: cannot open ..\Binaries\Win64\BlankProgram.exe for writing
See the attached log, which mentions the error.
We don’t use symlinks in our source setup.
Thanks a lot Henrik!
We’re indeed using incremental linking.
I’d be interested to know why no one uses incremental linking at Epic. Do you advise against it, especially under UBA ? If that means downloading extremely large dlls and exes on the agents… yeah
Thanks, I’ll look into it when we switch to 5.6 then, as ExtraRootPath is not available to us right now. But yeah that’s the issue: our plugins are stored in an unexpected place.
I believe you also did some work to share cache artifacts even when the absolute root path is different between machines?
Something else I forgot to report: in some source files we had fishy include directives that ended with a space after the filename. On native msvc/clang-cl this is not an issue because we didn’t notice them for years, but under UBA the compiler spits a file not found error.
#include "SomeFile.h "