Build issues with latest cesium-native and cesium-unreal from source

We are encountering build issues while trying to build the latest Cesium-native from commit e0770638f9a57d8a441c3bf4c02cf6bbd09b2ae1. Here are the details:

Environment:

  • Cesium-native commit: e0770638f9a57d8a441c3bf4c02cf6bbd09b2ae1
  • Cesium-unreal commit: ca6e385bf85fe481be630f39ad6a26e56cd23b22

Issue Description:

  1. The build process uses vcpkg for dependencies and automatically downloads them when running build-helper.sh
  2. In the .ezvcpkg/2024.07.12/ directory (in user directory), we found stb_image_resize2.h instead of the expected stb_image_resize.h, suggesting a package version mismatch
  3. We manually added the correct file which allowed us to build the Windows libraries. However, when compiling the plugin, weā€™re getting multiple errors related to override functions, despite them being present in the code

Questions:

  1. Is there a specific version of vcpkg we should be using?
  2. Whatā€™s the recommended process for building libraries from cesium-native with these commits?
  3. Has anyone else encountered similar override function errors during plugin compilation?

build.log.zip (3.4 KB)

Any guidance would be appreciated. Thanks!

Hi! You can try compiling again today.

if not, you can see the link(FlowUs ęÆ굁 - ꖰäø€ä»£ē”Ÿäŗ§åŠ›å·„具)怂 or email to me.

Now I can compile the cesium-unreal, but it doesnā€™t work in my computer. :sweat_smile:

the environment is
UE5.4.4
Visual Studio 2022 version 17.12.1

I think the reason that the MSVC version is different.
the Visual Studio 2022 17.12.1 will install the MSVC 14.42.34433, but UE5.4.4 is not suppot this verison.

you can see this [article( Unable to generate C++ project after upgrading to Visual Studio 17.12 [blocking])](Unable to generate C++ project after upgrading to Visual Studio 17.12 [blocking] - #26 by frankiezafe - Platform & Builds - Epic Developer Community Forums)

@Kevin_Ring we tried the latest MSVC but weā€™re still getting the same errors above. Anything else we can try?

@carlrealvr we donā€™t guarantee that cesium-unreal can compile against the head of cesium-native at all times. We often merge breaking changes into cesium-native and only later update cesium-unreal to work with them. It looks like you have chosen an incompatible combination.

The safest thing is to use a tagged cesium-unreal release, and the exact cesium-native commit that is referenced by the git submodule. Anything else might work at any given time, or it might not.

To answer your questions:

  1. The expected version of vcpkg is referenced in cesium-nativeā€™s CMakeLists.txt: cesium-native/CMakeLists.txt at v0.42.0 Ā· CesiumGS/cesium-native Ā· GitHub
  2. You canā€™t build cesium-unreal with those commits.
  3. Yep, we saw those errors when we updated to the new version of cesium-native in cesium-unreal, and then we fixed them: Update for schema changes in cesium-native by kring Ā· Pull Request #1552 Ā· CesiumGS/cesium-unreal Ā· GitHub
1 Like

@Kevin_Ring - Weā€™re experiencing something similar. In our case, we are trying to package Cesium native on MacOS (M3 Macbook Air, Sequoia 15.1.1, XCode 16.1 beta 3) initially for iOS and then to extend this for VisionOS, using the latest Cesium-Unreal commmit and the appropriate submodule ref for Cesium-Native:

Cesium-Unreal Commit: - 6d46dcba25a511889ea1cc2304c5b5823a002a27
Cesium-Native Commit: - 1ece56deca0cb068e720ae67ae716fe80ec231ac

Compiling Cesium Native for MacOS using the commands on Github complete succesfully:

  cmake -B build -S . -DCMAKE_BUILD_TYPE=Debug
  cmake --build build --target install

However when the subsequently run the corresponding iOS commands, I get errors on the build file command:

cmake -B build-ios -S . -GXcode -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCMAKE_BUILD_TYPE=Release

CMake Error at cesium-native/CMakeLists.txt:241 (find_package):
  Could not find a package configuration file provided by "Async++" with any
  of the following names:

    Async++Config.cmake
    async++-config.cmake

  Add the installation prefix of "Async++" to CMAKE_PREFIX_PATH or set
  "Async++_DIR" to a directory containing one of the above files.  If
  "Async++" provides a separate development package or SDK, be sure it has
  been installed.

From Cesium Nativeā€™s CMakeLists.txt, this looks like itā€™s linked to the search paths for the various dependencies, some of which vcpkg appears to be handling and others which are in other locations (eg Unreal Engine Open SSL).

# Find the VCPKG dependnecies
# Note that while we could push these into the extern/CMakeLists.txt as an organization tidy-up, that would require
# us to update the minimum version of CMake to 3.24 and to add the GLOBAL option to the find_package calls, otherwise
# they won't be visible in this scope nor any of the subdirectories for the actual libraries.
#
# However, for some of the vcpkg built libraries where they don't provide a prope cmake config file, we have to declare
# and imporeted library target ourselves. This is the case for modp_b64::modp_b64, picosha2::picosha2 and earcut. In
# these cases, we *do* have the somewhat ugly and verbose details in the extern/CMakeLists.txt file.

In some cases, all of these dependencies are installed via vcpkg, and adding specific variables (eg Async++_Dir) to specify the explicit folder appear to work, however not in all cases - and in any instance, this is not a robust/scalable solution.

Any suggestions on how to get this packaging would be amazing!

Hi @dagillespie,

Cesium-Unreal Commit: - 6d46dcba25a511889ea1cc2304c5b5823a002a27

I canā€™t find this commit. Perhaps itā€™s from your private fork of cesium-unreal or something?

Cesium-Native Commit: - 1ece56deca0cb068e720ae67ae716fe80ec231ac

This is the official v0.42.0 that we released this week.

However when the subsequently run the corresponding iOS commands, I get errors on the build file command:

I think youā€™re missing the necessary -DCMAKE_TOOLCHAIN_FILE="unreal-ios-toolchain.cmake". Take a look at how we build for iOS on CI:

I believe itā€™s specifically this line from the toolchain file that makes the search for the Async++ package work:

SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE BOTH)
1 Like

Amazing - thanks @Kevin_Ring! That has fixed things. The documentation page in the repo on setting up a dev environment for unreal-caesium for MacOS doesnā€™t include that one piece in the command - thank goodness for CI!

It also looks ā€œsuperficiallyā€ like it might now not be too much required to generate visionOS binaries either!

PS - yes I realise the repo was a commit from a fork of the main branch - apologies!

1 Like

@Kevin_Ring
We are able to build cesium-native 0.42.0 using the linux toolchain and package the plugin but when we try to package our project for Linux Server we get the attached build errors.

We are on Ubuntu 24.04 on WSL2, using clang-16 (16.0.6), llvm-16 and and ezvpkg 2024.11.16, and building the linux part of cesium-native with the following:

cmake -B build-linux -S . -DCMAKE_TOOLCHAIN_FILE=ā€œunreal-linux-toolchain.cmakeā€ -DCMAKE_POSITION_INDEPENDENT_CODE=ON && cmake --build build-linux --config Debug --target install && cmake --build build-linux --config Release --target installroot@ASROCK:/mnt/d/realvr/cesium-unreal-carl/extern

We build this in Linux Subsystem and package the cesium-unreal plugin in Windows. When we try to package a shipping build on Linux we see the attached errors:

linux_build.log.zip (1.5 KB)

Thanks!

@Kevin_Ring - many thanks again, Iā€™m able now to successfully compile for iOS and MacOS (seemingly compiling cerium-native for arm64, x64 and iOS without any errors) however when I then package the plugin, Iā€™m then unable to make use of the project as CesiumRuntime could not be loaded.

Unreal plugin packaging also didnā€™t report any errors.

Have you seen this before?

FYI - Iā€™m using Unreal 5.5.1 source build directly cloned from the 5.5 branch of Epicā€™s GitHub repo

See screenshot of error when opening a project with the newly packaged CesiumForUnreal plugin.

FYI - Iā€™m using the same commands AFAIK from buildApple.yaml but called through terminal via a bash script.

@Kevin_Ring

We built cesium-native using clang-16 on wsl2 because we were used to the cross compile toolchain on Windows for Linux uses clang 16.06, but we just noticed that the clang in the Linux version of UE5.3.2 is v23_clang-18.1.0-rockylinux8.

Should we point it at the clang in the Linux version of the Engine and rebuild cesium-native, maybe that will fix the errors we are seeing when trying to package our project?

Second question, weā€™ve been wondering if we actually need to build it using the clang 16.06 cross compiling toolchain in Windows, since that is what is actually being used to build our Linux server - havenā€™t been able to get that to work however, and you did say you build cesium-native for Linux on actual Linux?

(Please see previous post with questions right above dagillespie, hope it didnā€™t get lost)

Thanks!

@carlrealvr, @Kevin_Ring - my apologies for diverging from the topic here - I have started a new thread on the MacOS/iOS build topic to keep things cleaner here.

Errors building Cesium for Unreal for MacOS/iOS - Cesium for Unreal - Cesium Community

@Kevin_Ring sorry for the confusion. We look forward to your answers on the above two questions. Thank you.

Should we point it at the clang in the Linux version of the Engine and rebuild cesium-native, maybe that will fix the errors we are seeing when trying to package our project?

Yes, this is essential. Unreal will always try to link using its own toolchain. Compiling with your system toolchain and then using Unrealā€™s to link is very likely to cause linker errors. Use the same toolchain throughout and a lot less can go wrong.

weā€™ve been wondering if we actually need to build it using the clang 16.06 cross compiling toolchain in Windows, since that is what is actually being used to build our Linux server - havenā€™t been able to get that to work however, and you did say you build cesium-native for Linux on actual Linux?

Yeah we build the plugin on actual Linux. The GitHub Actions script that does it is here:

Which calls into here: