Repository navigation
Update physx 5.6.1 - #34
Open
amzn-changml wants to merge 38 commits into
Open
amzn-changml wants to merge 38 commits into
amzn-changml wants to merge 38 commits into
Conversation
Signed-off-by: Nicholas Lawson <70027408+nick-l-o3de@users.noreply.github.com>
Signed-off-by: Nicholas Lawson <70027408+nick-l-o3de@users.noreply.github.com>
Update build scripts to pull and package PhysX 5.6.1
I, iamjbq <119447878+iamjbq@users.noreply.github.com>, hereby add my Signed-off-by to this commit: 7d83f8b I, iamjbq <119447878+iamjbq@users.noreply.github.com>, hereby add my Signed-off-by to this commit: 58d8204 I, iamjbq <119447878+iamjbq@users.noreply.github.com>, hereby add my Signed-off-by to this commit: 6e218bd I, iamjbq <119447878+iamjbq@users.noreply.github.com>, hereby add my Signed-off-by to this commit: de52f48 Signed-off-by: Jason Q <119447878+iamjbq@users.noreply.github.com>
DCO Remediation Commit for Jason Q <119447878+iamjbq@users.noreply.github.com> I, Jason Q <119447878+iamjbq@users.noreply.github.com>, hereby add my Signed-off-by to this commit: 58d8204 Signed-off-by: Jason Q <119447878+iamjbq@users.noreply.github.com>
amzn-changml
force-pushed
the
3p-fix-storage
branch
from
May 9, 2026 03:50
865fb35 to
ed71082
Compare
Adds a conditional resize of the Linux GHA node, in the event the disk layout is not valid for resizing Signed-off-by: Mike Chang <62353586+amzn-changml@users.noreply.github.com>
- Taking over PR: o3de#368 from https://github.com/guillaume-haerinck - Updating CLANG_VER from 12 to 15 - Additional fixes for the file globbing issue, apply both approaches to capture both hidden files and symlinks. - Updated the build_package.yaml to use the included scripts instead of the on in 3p-packaging-scripts Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Related to o3de/o3de#19567, allow to build pyside6, which allow to use our Qt6 version with python tools. ## Where was it tested ? - Working on windows - Working on Ubuntu 24.04 --------- Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com> Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com> Co-authored-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Fix invalid QT5_COMPONENTS variable in qt_mac.cmake Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
The qt-6.10.2 Linux package builds the full Qt Wayland client stack (libqwayland.so, libQt6WaylandClient, shell integrations, client-side decorations, graphics integrations) but the deploy list only ships the xcb and minimal platform plugins. Since Qt 6 prefers Wayland in a Wayland session (default platform priority is wayland;xcb), every engine tool currently fails the wayland load and silently falls back to xcb over XWayland: qt.qpa.plugin: init_platform called with pluginNamesWithArguments "wayland;xcb" ... qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" qt.qpa.plugin: Successfully loaded Qt platform plugin "xcb" This also makes the engine's native Wayland protocol layer unreachable in deployed builds: the Editor enables it based on QGuiApplication::platformName() == "wayland", which can never be true when the plugin is not shipped. Ship the wayland QPA plugin plus its closure: libQt6WaylandClient and libQt6WlShellIntegration (the only non-system libraries the plugin set links), the shell integrations (xdg-shell is the one modern desktop compositors use), both client-side decoration plugins (needed for window decorations under compositors like Mutter that do not draw server-side decorations), and the client graphics integrations for the hardware (EGL) and shared-memory buffer paths. Everything else the plugins reference resolves from system libraries (libwayland-client, libwayland-cursor, libwayland-egl, libxkbcommon, libEGL). On X11-only systems the wayland plugin fails to load exactly as it does when absent and xcb is selected as before, so non-Wayland environments cannot regress. Bumps the Linux package to 6.10.2-rev6. Signed-off-by: Nick Schuetz <nschuetz@redhat.com>
…ination
With a distro Qt6 development package installed (e.g. Fedora 44 ships
qt6-qtbase-devel 6.11.1, newer than the bundled 6.10.2), configuring
against this package fails with:
CMake Error at /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsTargetsPrecheck.cmake:1
(_qt_internal_should_include_targets): Unknown CMake command
The top-level find_package(Qt6) correctly resolves the bundled
Qt6Config.cmake through the CMAKE_PREFIX_PATH entry, but the nested
find_package calls inside Qt's own config files (Qt6Config ->
Qt6CoreTools via QtPublicDependencyHelpers.cmake) search the standard
system prefixes and resolve the newer system Qt6, mixing config files
across Qt versions.
Pin <Pkg>_DIR for every package config dir shipped in the bundle before
the find_package(Qt6) call. find_package consults <Pkg>_DIR before any
search path, so all Qt-internal packages resolve from the bundle while
non-Qt finds (the system OpenGL that Qt6Gui needs) search normally.
NO_DEFAULT_PATH cannot solve this: alone it also disables the
CMAKE_PREFIX_PATH lookup and finds nothing; combined with PATHS it fixes
only the top-level call because it does not propagate into the nested
find_package calls.
Validated in a Fedora 44 container against qt-6.10.2-rev5-linux with
system qt6-qtbase-devel, qt6-qtsvg-devel and qt6-qttools-devel 6.11.1
installed: configure completes, every component resolves from the
bundle, and zero config files load from /usr/lib64/cmake.
Bumps the Linux package to 6.10.2-rev6. FindQt.cmake is shared with the
Mac-arm64 and Windows packages; they pick the change up at their next
rebuild.
Signed-off-by: Nick Schuetz <nschuetz@redhat.com>
…age dirs in FindQt.cmake (o3de#380) ## Summary The qt-6.10.2 Linux package builds the full Qt Wayland client stack but the deploy list ships only the `xcb` and `minimal` platform plugins, so deployed engine tools can never run native Wayland. This adds the wayland QPA plugin and its closure to the Linux deploy list. This is Linux pain point 2 from the QT6 Support Discord thread with @guillaume-haerinck. ## The behavior today Qt 6 prefers Wayland in a Wayland session (default platform priority is `wayland;xcb`). With `QT_LOGGING_RULES='qt.qpa.plugin=true'`, launching Project Manager from an installed qt6-branch engine build on a Fedora 44 GNOME Wayland session shows: ``` qt.qpa.plugin: init_platform called with pluginNamesWithArguments "wayland;xcb" ... qt.qpa.plugin: Attempting to load Qt platform plugin "wayland" with arguments QList() qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in "" qt.qpa.plugin: Attempting to load Qt platform plugin "xcb" with arguments QList() qt.qpa.plugin: Successfully loaded Qt platform plugin "xcb" ``` Qt tries Wayland first, fails because `libqwayland.so` is not shipped, and silently falls back to xcb over XWayland. Nothing in the engine or the package forces xcb; the deploy gap is the only blocker. This also strands engine code: the qt6 branch's native Wayland protocol layer (`AzFramework/Platform/Common/Wayland/`) is enabled from `Code/Editor/CryEdit.cpp` based on `QGuiApplication::platformName() == "wayland"`, which can never be true in a deployed build when the plugin is missing. ## What this adds All files already exist in the built package; this only extends the deploy list: - `platforms/libqwayland.so`: the QPA plugin. - `lib/libQt6WaylandClient.so` and `lib/libQt6WlShellIntegration.so`: the only non-system libraries the plugin set links (verified via the NEEDED closure of every plugin below; everything else resolves to system `libwayland-client`, `libwayland-cursor`, `libwayland-egl`, `libxkbcommon`, `libEGL`). - `wayland-shell-integration/` (all five): `xdg-shell` is what modern desktop compositors use; the others are small and keep parity with the built package. - `wayland-decoration-client/` (both): client-side decorations; without these, windows have no titlebars under compositors that do not draw server-side decorations (GNOME Mutter). - `wayland-graphics-integration-client/` (all three): the hardware (EGL) and shared-memory buffer-sharing paths. ## Non-Wayland environments On X11-only systems (including the Ubuntu AR images) the wayland plugin fails to load exactly as it does today when absent, and xcb is selected as before. Qt platform plugin loading is graceful, so this cannot regress non-Wayland environments. ## Validation The diagnosis is empirically validated (the qt.qpa.plugin trace above is from a live run of an installed qt6-branch build). The change itself is a deploy-list addition; once a rev6 Linux package is published and the engine pin updates, we will verify native-Wayland startup end-to-end on Fedora through our packaging test channel and report back. --- ## Summary (FindQt.cmake pinning, folded from o3de#379) With a distro Qt6 development package installed, configuring against the `qt-6.10.2-rev5-linux` package fails because nested `find_package` calls inside Qt's own config files escape to the system Qt. This pins `<Pkg>_DIR` for every package config dir shipped in the bundle before the `find_package(Qt6 ...)` call, so Qt-internal packages always resolve from the bundle. Discussed with @guillaume-haerinck in the QT6 Support Discord thread (Linux pain point 1). ### The failure Fedora 44 host (or container) with `qt6-qtbase-devel` installed (6.11.1, newer than the bundled 6.10.2): ``` CMake Error at /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsTargetsPrecheck.cmake:1 (_qt_internal_should_include_targets): Unknown CMake command "_qt_internal_should_include_targets". ``` The top-level `find_package(Qt6)` is not the problem: it correctly resolves the bundled `Qt6Config.cmake` through the `CMAKE_PREFIX_PATH` entry FindQt.cmake appends. The escape happens one level down. The bundled Qt6Core config resolves its tool package through `QtPublicDependencyHelpers.cmake`, whose `find_package(Qt6CoreTools)` searches the standard system prefixes and lands on `/usr/lib64/cmake/Qt6CoreTools` from the system Qt. The 6.11 config file then calls internal macros that do not exist in the already-loaded 6.10.2 machinery, and configure dies. Any system Qt6 newer than the bundled one triggers this. ### Why not NO_DEFAULT_PATH Both shapes were tested. `NO_DEFAULT_PATH` alone finds nothing (it also disables the `CMAKE_PREFIX_PATH` lookup the package relies on). `PATHS ... NO_DEFAULT_PATH` fixes only the top-level call: the option does not propagate into the nested `find_package` calls inside Qt's config files, so Qt6CoreTools still escapes and the error is identical. Two broader containment approaches also work (a `CMAKE_FIND_USE_*` hermetic window, and `CMAKE_IGNORE_PREFIX_PATH /usr;/usr/local;/`) but both also blind the nested `find_package(WrapOpenGL)` to the system libGL that bundled Qt6Gui legitimately needs, so they require an extra OpenGL pre-seed. The `<Pkg>_DIR` pinning has no side effects outside Qt packages. ### The fix `find_package` consults `<Pkg>_DIR` before any search path, so pinning every package dir shipped in the bundle short-circuits every nested Qt-internal find while non-Qt finds search completely normally: ```cmake file(GLOB _qt_bundled_pkg_dirs LIST_DIRECTORIES true "${QT_LIB_PATH}/cmake/*") foreach(_qt_bundled_pkg_dir IN LISTS _qt_bundled_pkg_dirs) if(IS_DIRECTORY "${_qt_bundled_pkg_dir}") get_filename_component(_qt_bundled_pkg_name "${_qt_bundled_pkg_dir}" NAME) set(${_qt_bundled_pkg_name}_DIR "${_qt_bundled_pkg_dir}") endif() endforeach() ``` ### Validation Fedora 44 container, `qt-6.10.2-rev5-linux`, harness consuming FindQt.cmake the same way the engine does (module path + `find_package(Qt REQUIRED MODULE)`), with system `qt6-qtbase-devel`, `qt6-qtsvg-devel` and `qt6-qttools-devel` 6.11.1 all installed: - Without the fix: the Qt6CoreTools error above. - With the fix: configure completes, `Qt6_DIR` and every component resolve from the bundle (`Qt6Core` at `.../qt/lib/libQt6Core.so.6.10.2`), and zero config files load from `/usr/lib64/cmake`. - Baseline (no system Qt installed) behaves identically before and after. ### Scope Bumps the Linux package to `6.10.2-rev6`. `FindQt.cmake` is shared with the Mac-arm64 and Windows packages, and both define `QT_LIB_PATH` the same way, so they pick up the same protection (against e.g. a Homebrew Qt6 on Mac) at their next rebuild; only the Linux rev is bumped here. Happy to bump those revs too if preferred. ## Rev note One rev bump for both changes: Linux goes to 6.10.2-rev6. (o3de#379 carried the same bump; it is folded here per review feedback and closed.)
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
* Add Mac-arm64 support for pyside6 - New build_mac.sh and package_mac.sh scripts * Fix host architecture selection for package.py Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Apply a linux pre-package RPATH fix to - bin/shiboken6 - lib/libpyside6.abi3.so.6.10 - lib/libpyside6qml.abi3.so.6.10 - lib/libshiboken6.abi3.so.6.10 Fixes o3de#378
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Fixes absolute path for shiboken_generator/shiboken6
Signed-off-by: Reece Hagan <drogonmar@tuyuji.com>
Signed-off-by: Reece Hagan <drogonmar@tuyuji.com>
We need `GuiPrivate` and `WaylandClient` to properly retrieve the `wl_display` from Qt. This is required for my Wayland PR thats coming up for the o3de repo. I'm not too familiar with the 3p system so let me know what changes are needed.
- Fix shiboken flags to use c++20 to match o3de and fix errors - Fix the RPATH settings for shiboken6 to work with using $QTDIR/bin as the current working directory (set to a relative ./../lib) for linux and mac to resolve libQtCore.so.6 - Add missing copy of the share folder into the package (needed for shiboken6) - Bump the revision to 4 - Tagged the windows github runner image to windows-2022 to lock in visual studio 2022 --------- Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
## Pyside6/Shiboken Fixes * Add compiler-path to Shiboken6 arguments to fix linux build error * Fix extension for generated files from shiboken: pyd is windows only, .so is linux/mac ## Qt6 Fixes * Adjust lrelease RPATH for special case where lrelease is copied to the O3DE bin folder * Suppress warning about using a private Qt header * Remove deprecated qt5.15 from package reference for linux --------- Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Bump version for expat for mac-arm64 to regenerate package that was never promoted to prod Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
Add -Wl,-z,max-page-size=16384 and -Wl,-z,common-page-size=16384 linker flags to the shared Android toolchain used by all 3p package builds. This ensures all Android shared libraries (.so) have ELF segments aligned to 16KB boundaries, as required by Google Play for apps targeting Android 15+ devices (enforced since November 1, 2025). 16KB-aligned libraries are fully backward compatible with 4KB-page devices -- no runtime behavior change on existing hardware. All packages that build for Android (expat, freetype, googlebenchmark, libpng, libsamplerate, Lua, lz4, mikkelsen, OpenSSL, tiff, zlib) use this shared toolchain and will automatically produce 16KB-aligned output on their next rebuild. Note: vulkan-validationlayers uses prebuilt Khronos binaries and will need an updated version from upstream separately. Signed-off-by: colinb <colinb@accesspointmg.com>
## Bump OpenSSL to 3.6.3 across all platforms Unifies the O3DE OpenSSL 3rdParty package to 3.6.3, replacing the 1.1.1. ### Changes - Linux, Linux-aarch64, and Mac/Mac-arm64: source builds now target `openssl-3.6.3`. - vcpkg path (Mac-Intel/iOS/Windows/Android): bumped the vcpkg pin to a commit shipping OpenSSL 3.6.3 natively; dropped the two legacy 1.1.1-era patches (`set_openssl_port_to_1_1_1_x.patch`, `enable-stdio-on-iOS.patch`); updated package metadata (OpenSSL changed to `Apache-2.0`). - fixed two stale prerequisite checks in testing script: the `qemu` package no longer exists on modern Ubuntu, and the aarch64 binfmt check now also recognizes kernel-level `binfmt_misc` registration ### Testing - Linux x86_64: built and tested end-to-end via the real Docker pipeline - vcpkg path: validated via a local Linux-triplet dry run of the new vcpkg pin - Linux-aarch64, Mac/Windows/Android/iOS: left to CI --------- Signed-off-by: Jan Hanca <jan.hanca@robotec.ai>
Bump revision for DirectX 5 for mac-arm64 because rev4 was never promoted to prod Signed-off-by: Steve Pham <82231385+spham-amzn@users.noreply.github.com>
## What does this PR do? Adds 16KB page size alignment linker flags to the shared Android toolchain used by all 3p package builds: ``` -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384 ``` This ensures all Android shared libraries have ELF LOAD segments aligned to 16KB boundaries, as required by Google Play for apps targeting Android 15+ devices (enforced since November 1, 2025). 16KB-aligned binaries are fully backward compatible with 4KB-page devices. All packages that build for Android through this toolchain (expat, freetype, googlebenchmark, libpng, libsamplerate, Lua, lz4, mikkelsen, OpenSSL, tiff, zlib) will produce aligned output on their next rebuild. Note: vulkan-validationlayers uses prebuilt Khronos binaries and needs an updated upstream version separately. ## RFC **Draft pending acceptance of RFC o3de/o3de#19936** (Android 16KB Page Size Support for O3DE Native Binaries). Depends on o3de#388 (build script modernization) for the packages to be rebuildable with a current NDK/CMake. ## Verification `llvm-readelf -l <lib.so>` on rebuilt output must show all LOAD segments with `Align 0x4000` or greater.
…3de#398) ## WHAT DO * adds `clean_between_configurations` option and docs for it! * Justification: some libraries like openimageio cache their own fetchcontent dependencies in a single location during **configure** instead of build, and then don't rebuild them regardless of the configuration requested, causing release to compile against debug dependencies, for example, if debug was configured first. This would not matter on windows if you could use the release dependencies in debug, or vice versa, but unfortunately, OpenImageiO depends on C++ libraries, not just C API libraries, which then causes iterator mismatches. * adds `set_env_vars` option, which allows build scripts to set additional environment variables for the build, as they need. * `additional_src_files` was not documented, but already existed. * added docs for it. * moved the `additional_src_files` copy operation until **after** all the git checkout and package downloading has happened, so that the additional files can copy/override the git checkout and package downloading (like a patch if necessary). OpenImageIO needed this because it asks for ZLIB in a very specific and irritating way, thus needing to patch the `FindZLIB.cmake` file. * Adds a check for if delete folder is about to delete a root folder of the machine, just in case. * There's already a function to apply a custom env var set, but it was only being applied during test. Now applies the custom environment variables requested to the configure and build steps, not just the test step, so that it is a uniform environment. * Adds `CMAKE_PREFIX_PATH` environment variable to any time the custom environment variable is used, and has it include the downloaded packages, so that the build can find them if they are requested via `find_package(CONFIG...)` which will not make use the `CMAKE_MODULE_PATH`. ## HOW TEST I've been using this upgraded script for a few weeks, to build Imath, OpenEXR, OpenImageIO, libTIFF, YAML-CPP, etc, they all rely on it, so its been copied into each of them. I figure that instead of doing that, we should just commit it once to the 3p repo, then they can all stack on top of it. --------- Signed-off-by: Nicholas Lawson <70027408+nick-l-o3de@users.noreply.github.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.