Burst does not support cross-compilation between Windows, Mac, or Linux

Just found out that Burst requires you to be running the same OS that you are building for, which is a nightmare for shipping an indie game!

I had no idea about this and am trying to ship my game for all platforms this year.

Are there any other solutions than buying an iMac and dual-booting to Linux?

 

You can just build for Mac OS in a virtual machine. I've been doing it for years for iOS builds (as the project requires CocoaPods making it so windows builds for iOS don't work.)

 

That's a good idea, I will try it out!

I didn't realize you could VM OSX. But I'm also targeting Linux, so the pipeline for making a build would be way too time-consuming. Especially compared to just building all of them from my Windows machine in one shot.

Will try Cloud Build, or I'll have to remove the plugins that use ECS.

 

Update: looks like Cloud Build doesn't support Burst. It properly created a windows build but failed on Burst compilation since they use Mac OS instances for building
https://forum.unity.com/threads/cloud-build-doesnt-support-burst-il2cpp.696055/

 

Is Linux build still not supported from Windows version of Unity?

 

I've recently seen several new packages in the package manager designed to help building DOTS for each platform.


I haven't tried and don't know if it helps in this situation but worth a try.

 

Not really sure what it does from the (very) limited documentation but installing it doesn't change anything for me. Cross-compiling from Windows to Linux still doesn't work with Burst.

 

We can only hope!

 

Any updates on this front? We have a linux build server that we'd like to use to generate Windows and Android builds. :|

 

In the latest preview of Burst you can build to Win/Mac/Linux on Windows at least, there's a thread somewhere in the unity forums but they haven't updated the documentation yet.

 

Well at least good to hear they're working on this. :| Wish they had a better roadmap.. or anything. really.

 

Yeah.. agreed.
Note that I'm not making use of Burst Compiler currently, but,

With Docker containers being so heavily focused on Linux, it feels like a massive disconnect between making automated builds on Docker containers vs. Unity currently.

Unity Cloud Build sounds awesome, but sometimes we may wish to use general software engineering tech, to diversify our knowledge, unify our tech stack (when using more than just Unity), etc.

I was able to run a successful build in a Docker container...
- Built FROM unityci/editor:ubuntu-2021.1.20f1-windows-mono-0.15.0
- (Thus, running a Linux container)
- Running on my Windows 10 Home laptop
- Using Docker Desktop for Windows
- Building a bare-bones, almost-empty Unity 2021.1.20f1 project
- Targeting Windows Mono build target
- Using the following command in a "build.sh" bash script:

Code (CSharp):

1. "$UNITY_FILE_PATH" -quit -batchmode -nographics -logfile "buildlog-$buildType.txt" -serial "$UNITY_SERIAL_NUMBER" -username "$UNITY_USERNAME" -password "$UNITY_PASSWORD" -projectPath . -executeMethod PXG.Editor.CommandLine.Builds.BuildPlayer -buildType "$buildType"

Where $UNITY_FILE_PATH=/opt/unity/Editor/Unity,
and I passed in the other 3 environment variables ($UNITY_USERNAME, $UNITY_PASSWORD, $UNITY_SERIAL_NUMBER) through my Windows Host OS,
$buildType is either CLIENT or SERVER for my game's 2 builds,
and PXG.Editor.CommandLine.Builds.BuildPlayer is the C# name of my private static void method that gets called into from command line.

However, in my real Unity 2021.1.20f1 project (not just a barely-empty project), the same Windows Mono build fails only in my Docker container, in the middle of shader compilation, with the following from the editor log file:

Code (CSharp):

1. Caught fatal signal - signo:11 code:1 errno:0 addr:0x968
2. Obtained 31 stack frames.
3. #0  0x007f6d31cc7980 in funlockfile
4. #1  0x007f6d34967fc4 in XAddExtension
5. #2  0x007f6d347399d1 in _XcursorGetDisplayInfo
6. #3  0x007f6d34739f29 in XcursorSupportsARGB
7. #4  0x007f6d34738724 in XcursorImageLoadCursor
8. #5  0x0055caa8f5c3b8 in Cursors::GenerateCursor(Texture2D*, Vector2f, CursorMode)
9. #6  0x0055caa8f5c066 in Cursors::InitializeCursors(Texture2D*, Vector2f)
10. #7  0x0055caa8eebcae in PlayerSettings::InitDefaultCursors()
11. #8  0x0055caa8eec43b in PlayerSettings::AwakeFromLoad(AwakeFromLoadMode)
12. #9  0x0055caa801a41b in ManagerBackup::ResetUserEditableManagers()
13. #10 0x0055caa916503d in DoBuildPlayer(BuildPlayerSetup const&, std::vector<EditorSceneBackup, stl_allocator<EditorSceneBackup, (MemLabelIdentifier)123, 16> >&, core::basic_string<char, core::StringStorageDefault<char> >, dynamic_array<core::basic_string<char, core::StringStorageDefault<char> >, 0ul>, bool, BuildReporting::BuildReport&, BuildReporting::BuiltAssetBundleInfo*, core::basic_string<char, core::StringStorageDefault<char> > const&)
14. #11 0x0055caa9169b50 in BuildPlayer(BuildPlayerSetup const&, BuildReporting::BuildReport&)
15. #12 0x0055caa8941344 in BuildPipeline_CUSTOM_BuildPlayerInternalNoCheck(ScriptingBackendNativeArrayPtrOpaque*, ScriptingBackendNativeStringPtrOpaque*, ScriptingBackendNativeStringPtrOpaque*, BuildTargetPlatformGroup, BuildTargetPlatform, BuildPlayerOptions, ScriptingBackendNativeArrayPtrOpaque*, unsigned char)
16. #13 0x00000040d4a36b in (wrapper managed-to-native) UnityEditor.BuildPipeline:BuildPlayerInternalNoCheck (string[],string,string,UnityEditor.BuildTargetGroup,UnityEditor.BuildTarget,UnityEditor.BuildOptions,string[],bool)
17. #14 0x00000040d49d80 in UnityEditor.BuildPipeline:BuildPlayerInternal (string[],string,string,UnityEditor.BuildTargetGroup,UnityEditor.BuildTarget,UnityEditor.BuildOptions,string[])
18. #15 0x00000040d49878 in UnityEditor.BuildPipeline:BuildPlayer (string[],string,string,UnityEditor.BuildTargetGroup,UnityEditor.BuildTarget,UnityEditor.BuildOptions,string[])
19. #16 0x00000040d49720 in UnityEditor.BuildPipeline:BuildPlayer (UnityEditor.BuildPlayerOptions)
20. #17 0x00000040d477dc in PXG.Editor.Builds.GameModeBuildHandler:BuildGame (UnityEditor.BuildPlayerOptions)
21. #18 0x00000040d448ef in PXG.Editor.CommandLine.Builds:BuildPlayer ()
22. #19 0x00000040d44b93 in (wrapper runtime-invoke) object:runtime_invoke_void (object,intptr,intptr,intptr)
23. #20 0x007f6c235abbf7 in mono_print_method_from_ip
24. #21 0x007f6c2371ba34 in mono_perfcounter_foreach
25. #22 0x007f6c2371c8e1 in mono_runtime_invoke
26. #23 0x0055caa7822c23 in scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)
27. #24 0x0055caa781eb97 in ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)
28. #25 0x0055caa80f8732 in Application::ParseARGVCommands()
29. #26 0x0055caa80f7706 in Application::FinishLoadingProject()
30. #27 0x0055caa857b935 in InitializeUnity(void*)
31. #28 0x0055caa857b334 in main
32. #29 0x007f6d318e5bf7 in __libc_start_main
33. #30 0x0055caa6b28029 in _start

I kind of have no idea where to go from here haha...

 

Hmm.. then again, it looks like I should be able to run my Unity Test Framework tests, and builds with Unity Cloud Build.

Even though I love and want to use Docker/containerization,
I could still use Docker for running my game server itself.

Sounds like the best of both worlds actually.
Welp thanks for listening, I know what I'm doing now

 

With much gnashing of teeth, we do run Unity 2020.3 in Docker and run our tests and (development/mono) builds there.

More info here if you're curious:
https://johnaustin.io/articles/2020/running-unity-20201-in-docker

 

Wow, thanks!!
I was just reading your blog post from 2020 about Docker and Unity if I recall correctly

 

Hah, glad it was helpful!