Can't build with the CoreCLR experimental backend

image

it says “Currently selected scripting backend (CoreCLR) is not installed.”

I did install the module for Mac CoreCLR builds, and I restarted. So I’m confused

Can you screenshot the whole build profiles window? And show the list of components you installed via the hub?

I’ve got the same issue.

All that I have enabled in the profile:

Modules definitely installed:

Hi, I found the issue. The CoreCLR Build Support installer drops some player variation folders in the wrong place:

  • <EditorRoot>/Variations/

instead of:

  • <EditorRoot>/PlaybackEngines/MacStandaloneSupport/Variations/, which is where the Editor actually looks. That’s why it reports CoreCLR as “not installed” even though the files exist.

Workaround: move everything under <EditorRoot>/Variations/ into <EditorRoot>/PlaybackEngines/MacStandaloneSupport/Variations/, then restart the Editor. This fixed it in my testing. I’m filing a bug so it’s fixed at the installer level

This makes it build, but running doesn’t get far - opening the app ends silently right away. No logs are created that I can see.
This is a fairly clean and fresh project with just a few assets added, and still with the sample scene configured.

Switching to IL2CPP gives me a new error:
Building Library/Bee/artifacts/MacStandalonePlayerBuildProgram/as3cq/GameAssembly.dylib failed with output:
Undefined symbols for architecture arm64:
“SkinDeformBatchedJob_1_CopyBuffer_mFB7CFFE584A42E30E6D04D85457632DEAE2E6249_fshared_inline(unsigned char*, unsigned char*, int, int, MethodInfo const*)”, referenced from:
_ReversePInvokeWrapper_SkinDeformBatchedJob_1_CopyBuffer_m80F94597588E1FBBEEFE1FF4523670C0B4582B3D in 3gezjon9a6jv.o
_ReversePInvokeWrapper_SkinDeformBatchedJob_1_CopyBuffer_mD4E5196A2A34BA57BB5014D8DA93DDBF28CDD848 in 3gezjon9a6jv.o
ld: symbol(s) not found for architecture arm64
clang++: e[0;1;31merror: e[0me[1mlinker command failed with exit code 1 (use -v to see invocation)e[0m

UnityEditor.EditorApplication:Internal_CallDelayFunctions () (at /Users/bokken/build/output/unity/unity/Editor/Mono/EditorApplication.cs:428)

Switching to Mono is the only option that gives me a runnable app.

Could you shared the player logs from the CoreCLR build?

macOS ~/Library/Logs/Company Name/Product Name/Player.log

I switched to CoreCLR. It didn’t take, I noticed after running through a Mono build. Changed it again, and it finally remained at CoreCLR.
Ran the build, and this is the entire log:

Initialized ClrProfiler
libc++abi: terminating due to uncaught exception of type PAL_SEHException

So, just to verify it wasn’t just my project importing a bunch of stupidly broken things (unlikely - it’s all sprites + TMP), I made a clean project with zero additions based on the blank 2D template. Set it to CoreCLR, and it’s also not launching. But what’s weirder is the log:

Initialized ClrProfiler
mono: initialization failed
Failed to load mono, aborting

What?

IL2CPP build actually worked for this.

So to verify extra well I switched to a prototype I made earlier this week, and had only ever run in Mono and web export.
Same CoreCLR results as the entirely blank project.

What exact OS version and hardware are you on? We will attempt to reproduce it.

Could you also file a bug report via the editor? That should capture most of the information we need.

I’m on macOS 26.4.1 at the moment. I’ll file a report a bit later.

Updated OS and reproduced. Reported as IN-148625.

Nobody at UT can reproduce this. It’s still not working for me, and the player logs only show 2-3 useless lines. No CoreCLR build runs for me outside the editor.

In the process, I also discovered the bug reporter just grabs everything in Unity’s log directory, which I reported as a bug. Some old games have put crap in there, so there was a 250MB Player.log that your staff insisted was mine.

I just tested 6.7a3, and the CoreCLR package is STILL broken. Reported.

Wasn’t this supposed to be fixed by now?

Yes, it’s not brilliant. At least it now actually runs, with the stripping set to the lowest. Still would like to remove the roughly 30MB of fat from the player binary, but It’s acceptable for testing and platform parity.

The installers issue was fixed in 6000.7.0a4 (it missed 6000.7.0a3 cut off by a day or so). We’re still working on figuring out what that libc++abi: terminating due to uncaught exception of type PAL_SEHException is (it doesn’t reproduce on any of our machines). But we will get to the bottom of it.

The PAL_SEHException error basically means .Net saying “I have no idea!” if I read it right. Fun!