CesiumForUnityNative error on vanilla setup!?

[Drew55]

Hi friends, long time Unity dev, currently using Unity 2022.3.9 on macOS 10.14.

I followed the steps for the QuickStart and was trying to evaluate Cesium for our software. Once the package is installed, I immediately get slammed with error messages – screenshot attached.

DllNotFoundException: CesiumForUnityNative-Editor assembly:<unknown assembly> type:<unknown type> member:(null)
Reinterop.ReinteropInitializer..cctor () (at ./Library/PackageCache/com.cesium.unity@1.6.1/Editor/generated/Reinterop/Reinterop.RoslynSourceGenerator/ReinteropInitializer.cs:280)

[joseph.kaile]

Hello, I just tested package 1.6.1 in Unity 2022.3.9 on both Intel and Silicon and it worked.

Does Cesium Unity Samples work? Or importing into a blank project?

[Drew55]

Hi Joseph, appreciate your support on this – we’re looking forward to getting started integrating with Cesium.

I created a fresh blank URP project and repeated the QuickStart and same result.

Best guess is a macOS 10.14 issue? Can’t see how that is leading to this but I suspect that’s the repro for this over there. I recognize it’s older, but when it comes to production we have our methods. Hopefully, y’all get that and already want to keep the requirements flexible.

Thanks Joseph

[joseph.kaile]

@Drew55, we see that Unity 2021.3 runs on macOS 10.13 and above. We will look into making the plugin compatible with the older versions.

We created an issue here: Target macOS 10.13+ when compiling the native code · Issue #367 · CesiumGS/cesium-unity · GitHub

Thanks

[joseph.kaile]

Hello, I wrote a fix for it ( Make the project compatible with OSX 10.13 by joseph-kaile · Pull Request #368 · CesiumGS/cesium-unity · GitHub) but I don’t have an older Macintosh to test it myself. I was wondering if you could help me out by trying it on your computer and letting me know if it works. The link to the fix is here ( make the project compati le with osx 10.13 · CesiumGS/cesium-unity@c9a7d8a · GitHub at the bottom where it says MacOS package. To use it, you need to import the package as a tar file.

I really appreciate your help and feedback.

[Drew55]

Your attention on this is appreciated, thank you and glad I am “helping”.

Struggling to try this build change as I see no com.cesium.unity/native dir. Been a rough week here so unfortunately not able to pony up the time to get into learning the build steps. If that’s documented, I’ll try it or otherwise happy to take the new build products you have and I can drop them in here to confirm the fix.

[Drew55]

Hi Joseph,

Many thanks on your efforts and apologies on the delated response – many fires to fight here as we stand our exciting new title up that we’re pretty sure Cesium will really enjoy seeing.

Current status is still broken on out 10.14 workstations. I install 1.6.4 from the Cesium Unity Package Manager I get this now:

DllNotFoundException: CesiumForUnityNative-Editor assembly:<unknown assembly> type:<unknown type> member:(null)
Reinterop.ReinteropInitializer..cctor () (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/generated/Reinterop/Reinterop.RoslynSourceGenerator/ReinteropInitializer.cs:280)
Rethrow as TypeInitializationException: The type initializer for 'Reinterop.ReinteropInitializer' threw an exception.
CesiumForUnity.IonTokenTroubleshootingWindow.GetTroubleshootingDetails () (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/generated/Reinterop/Reinterop.RoslynSourceGenerator/IonTokenTroubleshootingWindow-generated.cs:13)
CesiumForUnity.IonTokenTroubleshootingWindow.set_ionAsset (CesiumForUnity.CesiumIonAsset value) (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/IonTokenTroubleshootingWindow.cs:135)
CesiumForUnity.IonTokenTroubleshootingWindow.ShowWindow (CesiumForUnity.CesiumIonAsset ionAsset, System.Boolean triggeredByError) (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/IonTokenTroubleshootingWindow.cs:245)
CesiumForUnity.IonTokenTroubleshootingWindow.ShowWindow (CesiumForUnity.CesiumRasterOverlay overlay, System.Boolean triggeredByError) (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/IonTokenTroubleshootingWindow.cs:183)
CesiumForUnity.CesiumIonRasterOverlayEditor.DrawTroubleshootButton () (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/CesiumIonRasterOverlayEditor.cs:57)
CesiumForUnity.CesiumIonRasterOverlayEditor.OnInspectorGUI () (at ./Library/PackageCache/com.cesium.unity@1.6.4/Editor/CesiumIonRasterOverlayEditor.cs:40)
UnityEditor.UIElements.InspectorElement+<>c__DisplayClass72_0.<CreateInspectorElementUsingIMGUI>b__0 () (at /Users/bokken/build/output/unity/unity/Editor/Mono/UIElements/Inspector/InspectorElement.cs:713)
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr, Boolean&) (at /Users/bokken/build/output/unity/unity/Modules/IMGUI/GUIUtility.cs:190)

[Drew55]

Happy to work with you test builds to get this running for your supported target family.

I can support you with cmake experimentation that you direct, please just lmk on specifics to make it happen.

Also, if your lab just spent $100 on a 5 year old mac-mini, you’d be able to run 10.14 on it and would be a great test machine. We’ve got a stack of them here, so happy to gift one to y’all and send it out to reflect the goodwill we have towards Cesium here.

[Drew55]

As a data point, I made an empty URP project with 2022.3.12 (what we’re using) and placed the x86_64 Cesium dylibs & meta files in the Asserts dir, along with a .cs declaration:

[DllImport("CesiumForUnityNative-Editor", CallingConvention=CallingConvention.Cdecl)]
private static extern byte initializeReinterop(ulong validationHash, IntPtr functionPointers, int count);

Same error, suggesting a fatal dynamic linking bootstrap error (presumably due to macOS version). On a Mac Pro 2013, stock 10.14.

[Kevin_Ring]

@Drew55 can you inspect the CesiumForUnityNative-Editor.dylib file that we’re shipping and determine what 10.14 doesn’t like about it?

[Drew55]

Hi Kevin, appreciate your attention on this!

Managing a tough worklist here as we enter alpha, so troubleshooting CesiumForUnityNative-Editor.dll more than I have is difficult at the moment. We’d love our product to have Cesium support, but we need to ensure that 10.14 is supported.

I shipped software all though Apple’s transition to 64 bit (10.5-10.7) so I know how nuanced and time consuming it is to deal with runtime linking problems! Unfortunately, all my kernel and DLL xp is with Mach-O and Win32, so troubleshooting a .NET library is out of my wheelhouse. Happy to run whatever macOS command line binary checks you would like me to. Alternatively, let me knowhow to get a hold any Unity / OS loading error log into that will help y’all crack this and I’ll jump on that. The key question is: what layer has access to load failure reason – par for the course that Unity’s DllNotFoundException contains zero useful information sigh.

Thanks!
Drew

[Drew55]

[Kevin_Ring]

@Drew55

Unfortunately, all my kernel and DLL xp is with Mach-O and Win32, so troubleshooting a .NET library is out of my wheelhouse.

CesiumForUnityNative-Editor.dll (actually I think it’s .dylib on macOS) is not a .NET library. It’s pure native C++ code. I don’t know how to use the macOS developer tools well enough to give you detailed instructions either, and we have a tough worklist ourselves. Perhaps the answers here provide some useful suggestions:

How to find which shared library is missing?

[Drew55]

Hi Kevin, appreciate your response.

Not sure if you saw the details in my followup posts. The error is for CesiumForUnityNative-Editor.dll.

aomeara$ otool -L  /Users/aomeara/git.arcspace/arcspace.unity-app/Library/PackageCache/com.cesium.unity@1.6.4/Editor/CesiumForUnityNative-Editor.dll 
llvm-objdump: error: /Users/aomeara/git.arcspace/arcspace.unity-app/Library/PackageCache/com.cesium.unity@1.6.4/Editor/CesiumForUnityNative-Editor.dll': object is not a Mach-O file type.

I’m rather surprised that Cesium isn’t tested on an OS version that is supposed to be supported – making us here wonder if Cesium is what we should be going with. As a former Apple dev, and every other company I’ve stepped foot in that ships software, there is a room full of older machines and OSes to test and QA on. A team would be in huge trouble if they didn’t QA on the supported OS versions. I get that 10.14 isn’t a spring chicken, but its successor is only 4 years old. My understanding is that Cesium gets the importance of compatibility (especially in the context of DoD contracts and deployments) – so I’m really scratching my head here.

We’re almost out of waiting time to have this figured out (this issue has been open for two months now). We’re a small shop and we are unfortunately too saddled to troubleshoot this issue for Cesium more than we already have. If someone over there has authority to add a $300 budget item for an old mac with 10.14, it can be found very easily and cheaply. The cost spent by both us and Cesium as this point has already exceeded multiples of this. Somehow if that is not available, I was serious about gifting Cesium a mac with 10.14 on it to move this forward even though we are a fraction of your size.

Sorry to be short with y’all, it’s just that the quick and easy answer to this is to have a QA machine there.

Thanks,
Drew

[Drew55]

In support of my previous message, I tasked someone to do a vanilla test on our vanilla 10.13 machine that we do QA on – and it also failed with the same errors I reported two months ago:

Sorry, I can’t spend any more resources on this issue to troubleshoot not working on both 10.13 and 10.14. We love Cesium and want to use it as our geo solution for our forthcoming Unity-based multimedia player.

[Kevin_Ring]

The error is for CesiumForUnityNative-Editor.dll.

No, CesiumForUnityNative-Editor.dll is a Windows DLL. It’s not loaded on macOS at all. The error message from Unity says “DllNotFoundException: CesiumForUnityNative-Editor assembly”, but that should not be interpreted to literally mean it’s a .dll file. The exception name comes from .NET’s Windows-specific history. The relevant file on macOS is either Editor/arm64/libCesiumForUnityNative-Editor.dylib or Editor/x86_64/libCesiumForUnityNative-Editor.dylib, depending on your processor architecture.

I’m rather surprised that Cesium isn’t tested on an OS version that is supposed to be supported

Unity 2021.3 supports 10.14 (probably because it’s several years old), but Apple doesn’t. According to this site, macoS 10.14 has been obsolete since 25 Oct 2021. Only a small fraction of our users use macOS in general. As far as I know you’re the only one using 10.x. (11.0 is three years old already).

As a former Apple dev, and every other company I’ve stepped foot in that ships software, there is a room full of older machines and OSes to test and QA on.

I think you might be overestimating the size of Cesium. We try to test on a variety of hardware, but that definitely does not include obsolete versions of macOS right now.

Look, the truth of the matter is that Cesium for Unity is a free and open source product, and there are a huge number of things competing for our development time. Something like this, where we don’t know what the problem is, we don’t have the hardware to test it, it’s an operating system that isn’t even supported by Apple anymore, and there is exactly one user running into the problem? We can’t justify much time on that. Would you?

That said, I’ve asked Joseph on my team to take a quick look at it to see if there’s something simple we’ve missed when we added what we thought was the necessary compiler option before.

But the beauty of open source is that you don’t need to rely on us. If this is important to your business, but not so much to ours, then you can invest the resources into fixing it yourself. And then we would almost certainly accept the PR so that you don’t have to maintain a fork going forward. If that is somehow not worth it and switching to another product is a better alternative for you, I’m very surprised, but I understand.

[Drew55]

Hi Kevin, I appreciate the quick response.

Apologies, it looks like I was under some mistaken impressions of Cesium based on its business aspirations and existing presence. I was under the impression that supporting 10.14 mattered and there were resources there.

And you’re absolutely right that 10.14 is obsolete and didn’t mean to posture otherwise. I was just pointing out that it has only been superseded a little over 4 years. That’s a long time to rich and privileged westerners like us, but to the underserved places we make our software for, it is very common they can only afford one device per home or are unable to upgrade further because of older hardware (such as a mac mini). Curious if you’ve seen the state of many community centers in poor areas. This is why we test extensively on older hardware and OSes.

My colleagues and I are ex-military and are trying to bring logistics tools like the US military has has for may years to poor areas and 2nd world regions that are in need for community planning tools for sustainable living and structure. If you are curious to learn more about our non-profit mission, it is quite exciting how we are using Unity (and prospectively Cesium) for humanitarian purposes. What you see on that website is 3 years old now and the alpha of the successor is a few months away. The debate here has been if Cesium will work satisfactorily on modest devices. So, yes, it is important in our opinion to have maps running on OSes that are more than a few years old.

And can we agree that Apple makes all kinds of stuff intentionally obsolete because they know it forces people to upgrade?

Drew O’Meara