I’m building a dedicated server for Linux (CentOS) on my Windows machine using source UE 4.18 and this batch file:
call c:\Unreal\UnrealEngine-release-4.18\Engine\Build\BatchFiles\RunUAT.bat ^
BuildCookRun -project="c:\GameArtists\Unreal\D1M1Arena\Unreal\D1M1Arena.uproject" ^
-nop4 -build -cook -compressed -stage ^
-noclient -server -serverplatform=Linux -serverconfig=Shipping ^
-pak -archive -archivedirectory="c:\GameArtists\Unreal\D1M1Arena\Unreal\Build " ^
if I try to build using v10_clang-5.0.0-centos7 I get error: specified path differs in case from file name on disk
I checked, I have these files on disk with the same exact case. For example, this is a file path from disk, like it is:
if I use v9_clang-4.0.0-centos7 and blueprint nativization setting in DefaultGame.ini - it fails with one of the blueprints failing with fatal error: UTF-16 (LE) byte order mark detected ([see file])
There are no errors if I use toolchain v9_clang-4.0.0-centos7 and blueprint nativization is disabled. Also, there are no errors in 4.17 and BP nativization enabled.
This is the line that’s causing the encoding to switch to UTF-16:
UFunction* ReturnFunction = static_cast(StaticFindObjectFast( UFunction::StaticClass(), Outer, TEXT(“GetТехт_Attributes”) ));
It appears that may have been overlooked and we’re not translating that occurrence to the other form.
Are you talking about: Get\xd0\xa2\xd0\xb5\xd1\x85\xd1\x82_Attributes ?
Cool, yeah if that wasn’t intentional I’d check your Blueprint asset in the editor and correct the function name there, then rebuild the cooked target with Blueprint nativization enabled. That should do the trick.
Indeed, I opened in the hex editor - The word Text has weird characters. I wander how did that happen… Will test soon, to confirm if that fixed that issue.
Cool, that actually helped with nativization, any ideas about v10_clang-5.0.0-centos7 ?
I don’t unfortunately, that’s not really my area. =(
I’ve entered a new issue for you on that one, it should eventually become available here.
For some reason the disk drive is spelled with a small “c” letter, which causes a case-sensitivity warning. Arguably in this case it should not apply (hard to imagine a path with "C:" in it being portable), but that unfortunately would need fixing in clang. You can remove -Wnonportable-include-path from LinuxToolChain.cs, although I would try to first fix the reason for lowercase “c”.
According to Windows, my drive is not “C”, it is “c”, so path is actually correct.
RCL, it does not look like “-Wnonportable-include-path” is in LinuxToolChain.cs: \Engine\Source\Programs\UnrealBuildTool\Platform\Linux\LinuxToolChain.cs
Ah yes, the warning is enabled by -Wall perhaps, so you rather need to add
Result += " -Wno-nonportable-include-path";
As for the drive name being lowercase - I wonder how it happened. The UBT is perhaps assuming that the drive letters are always uppercase and is not prepared to handle a situation like this.
This response helped me fix the same issue. Make sure you pass the upper case drive letter in all RunUAT command line arguments (and that the rest of the path match in case)