OCCT: Update to v8.0.0 (V8_0_0_p1)#14115
Open
ahojukka5 wants to merge 12 commits into
Open
Conversation
Bumps OCCT from 7.9.3 to the 8.0.0 release line (V8_0_0_p1 hotfix tag). Upstream reorganized the source tree under per-module directories (e.g. src/OSD -> src/FoundationClasses/TKernel/OSD), so all bundled patches are retargeted to their new paths, and two of them (CMakeLists.txt.patch, OSD_signal.cxx.patch, STEPConstruct_AP203Context.cxx.patch) are updated to match upstream context/API changes (Vcpkg install layout option, Standard_Boolean -> bool, and a new FreeBSD-specific timezone code path). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the Yggdrasil recipe for OCCT to the 8.0.0 release line (pinned to upstream hotfix tag V8_0_0_p1) and adjusts bundled patches to match OCCT’s reorganized 8.0 source tree layout.
Changes:
- Bump
OCCTfromv7.9.3tov8.0.0and update the pinned upstream Git commit. - Retarget all bundled patches to OCCT 8.0’s new module directory structure, with small context adjustments where upstream changed.
- Keep the build configuration/toolkit product list consistent with prior releases while adapting patch application by platform.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| O/OCCT/build_tarballs.jl | Bumps version/commit and keeps platform-conditional patching + CMake configuration for OCCT 8.0. |
| O/OCCT/bundled/patches/CMakeLists.txt.patch | Forces non-Windows install layout defaults for mingw builds; updates cached layout option strings for OCCT 8.0. |
| O/OCCT/bundled/patches/OSD_MemInfo.cxx.patch | Retargets the musl-related memory info patch to the new OCCT 8.0 source path. |
| O/OCCT/bundled/patches/OSD_signal.cxx.patch | Retargets the musl signal-handling patch to the new OCCT 8.0 source path and updated signatures. |
| O/OCCT/bundled/patches/Standard_CString.cxx.patch | Retargets FreeBSD locale/xlocale build workaround to the new OCCT 8.0 source path. |
| O/OCCT/bundled/patches/Standard_StackTrace.cxx.patch | Retargets the musl/FreeBSD stack-trace patch to the new OCCT 8.0 source path (and alters the fallback logic). |
| O/OCCT/bundled/patches/STEPConstruct_AP203Context.cxx.patch | Retargets the FreeBSD timezone cast fix to the new OCCT 8.0 source path. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
CI failed on all Linux/macOS/mingw platforms: Bnd_Box's "constexpr Bnd_Box() noexcept = default" is implicitly deleted by GCC because its default member initializers call RealFirst()/ RealLast(), which are constexpr but not noexcept, making the implicit exception specification noexcept(false) and mismatching the explicit noexcept on the defaulted constructor. Mark RealFirst()/RealLast() (and the analogous IntegerFirst()/ IntegerLast()) noexcept in the bundled patches, since they can never actually throw. This is a general fix for OCCT's own Standard_Real.hxx/Standard_Integer.hxx headers, applied unconditionally rather than per-platform. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
x86_64-apple-darwin failed with "'shared_mutex' is unavailable: introduced in macOS 10.12" and "'visit<...>' is unavailable: introduced in macOS 10.14" -- OCCT 8.0's Standard_ErrorHandler and Plugin now use std::shared_mutex/std::variant, which libc++ marks unavailable below the deployment target implied by the toolchain's default (10.10). Bump MACOSX_DEPLOYMENT_TARGET to 10.15 for this platform, matching the precedent in Trilinos's build_tarballs.jl for the same class of issue. aarch64-apple-darwin is unaffected since its baseline is already macOS 11+. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
x86_64-linux-gnu-cxx11, x86_64-apple-darwin, and aarch64-apple-darwin all failed the same way: "Built OCCT but libTKDEGLTF still unsatisfied". TKDEGLTF's EXTERNLIB.cmake requires CSF_RapidJSON (unchanged from 7.9.3), and adm/cmake/rapidjson.cmake only finds it via find_path/find_package against system/3rdparty search paths -- there's no vendored copy in the OCCT source tree. Without it, CMake silently drops the TKDEGLTF target instead of failing loudly. Add rapidjson_jll (header-only) as a Dependency, matching how Arrow, Octave, and xrt already consume it elsewhere in this repository. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adding rapidjson_jll as a Dependency alone did not fix the
"libTKDEGLTF still unsatisfied" audit failure -- adm/cmake/rapidjson.cmake's
find_path()/find_package() fallback still wasn't picking up the headers.
Pass -D3RDPARTY_RAPIDJSON_INCLUDE_DIR=${includedir} directly, which is
exactly where BinaryBuilder stages Dependency headers ($prefix/include,
the same location SYSROOT/usr/local is symlinked to). Unlike CMake's
own cached find_path result, a command-line -D always overwrites the
cache entry, so this is robust regardless of any prior cached
CMakeCache.txt state.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found the real root cause by reproducing the CMake configure step
locally with full (non-truncated) output, which the Buildkite log
API was hiding by only returning the last 2MB of these long logs.
OCCT's CMakeLists.txt gates TKDEGLTF/TKXSDRAWGLTF behind a *separate*
USE_RAPIDJSON opt-in toggle, checked independently of whether
CSF_RapidJSON/3RDPARTY_RAPIDJSON_INCLUDE_DIR actually resolve to
something real:
OCCT_IS_PRODUCT_REQUIRED (CSF_RapidJSON CAN_USE_RAPIDJSON)
if (CAN_USE_RAPIDJSON AND USE_RAPIDJSON)
...
else()
list (REMOVE_ITEM BUILD_TOOLKITS TKDEGLTF)
list (REMOVE_ITEM BUILD_TOOLKITS TKXSDRAWGLTF)
message(STATUS "Info: TKDEGLTF and TKXSDRAWGLTF toolkits excluded due to RapidJSON usage is disabled")
endif()
Since USE_RAPIDJSON defaults OFF, TKDEGLTF was silently dropped from
the toolkit list regardless of the two earlier fixes (adding the
rapidjson_jll dependency and pointing 3RDPARTY_RAPIDJSON_INCLUDE_DIR
at it) -- CMake even warned that the manually-specified
3RDPARTY_RAPIDJSON_INCLUDE_DIR variable was unused, because
adm/cmake/rapidjson.cmake is only included once USE_RAPIDJSON is on.
Verified locally: with -DUSE_RAPIDJSON=ON added, the exclusion
message disappears and `TKDEGLTF` appears as a real build target.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bumping MACOSX_DEPLOYMENT_TARGET alone wasn't enough: x86_64-apple-darwin still failed at link time with "undefined symbol: typeinfo/vtable for std::bad_variant_access" -- the bundled SDK's libc++ stub (.tbd) simply predates that symbol's existence, regardless of the requested deployment target. Swap in the MacOSX11.3 SDK before building, the same fix already used by Trilinos's build_tarballs.jl for the identical class of issue. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
x86_64-apple-darwin failed immediately after "Update SDK version": rm -rf on the old SDK's System dir hit "I/O error" on a bunch of framework Headers/Modules symlinks (an overlayfs quirk), and the script's `set -e` aborted the whole build on that non-zero exit, before ever reaching cmake. The subsequent cp -ra overwrites same-named entries regardless, so tolerate a non-clean rm instead of treating it as fatal. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous || true only covered rm; the leftover libxml2/libxml entry that rm couldn't remove then made the subsequent cp -ra fail with "File exists", still aborting the script under set -e. OCCT never touches libxml2, so drop that rm entirely and just tolerate per-item cp failures -- we only need the new SDK's symbols added/overwritten, not a byte-for-byte clean directory swap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
x86_64-apple-darwin hung for over an hour in BinaryBuilder's post-build audit after the previous fix, seemingly while resolving a broken/circular symlink left behind by the tolerant-of-failure System/Frameworks tree swap. Narrowed down the actual need: the linker error was specifically about std::bad_variant_access being completely absent (not just availability-gated) from the bundled SDK's usr/lib/libc++.tbd -- confirmed by grepping the real MacOSX11.3.sdk archive, where usr/lib/libc++.1.tbd (the libc++.tbd symlink's target) does contain __ZTISt18bad_variant_access / __ZTVSt18bad_variant_access. Only copying those two small stub files over is enough; no need to touch System/Library/Frameworks at all, which sidesteps the whole rm/cp overlayfs mess and the audit hang. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The libc++.tbd-only fix resolved bad_variant_access, but linking libTKService then failed on "undefined symbol: objc_alloc_init" -- missing from the bundled SDK's libobjc.A.tbd entirely, same class of issue as before. Rather than keep patching one .tbd at a time, replace the whole flat usr/lib/*.tbd set (281 small text stub files, ~3MB) with the newer SDK's versions. Still deliberately not touching System/Library/Frameworks, which is the actual source of the previous audit hang. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
aarch64-apple-darwin hung during the post-build audit in the previous run (build 30733), in the same way x86_64-apple-darwin once did, but this target never touches the x86_64-apple-darwin-only SDK-swap code, so it's unrelated to the recipe -- likely a stuck/loaded build agent. Retriggering to get a fresh run.
ahojukka5
added a commit
to ahojukka5/Monge.jl
that referenced
this pull request
Jul 3, 2026
OCCT_jll 8.0.0 isn't published to the General registry yet -- it comes from JuliaPackaging/Yggdrasil#14115 (not yet merged), which adds RapidJSON support and unblocks native glTF/GLB export. Manifest.toml currently deps on a local dev build at ~/.julia/dev/OCCT_jll (built via BinaryBuilder from the PR branch); this needs replacing with a normal registry version once the PR merges and OCCT_jll 8.0.0 is published. libopencascade_cxxwrap rebuilt against it (Artifacts.toml bump) -- required the two fixes in the OpenCascadeCxxWrap_jll commit that precedes this one.
ahojukka5
added a commit
to ahojukka5/OpenCascadeCxxWrap
that referenced
this pull request
Jul 18, 2026
Standard_Failure now derives directly from std::exception (not Standard_Transient) in OCCT 8.0, so DynamicType() no longer exists on it -- occ_guard's fallback message now uses the new ExceptionType() method, and prefers what() (Standard_Failure's own std::exception override) over the now-deprecated GetMessageString(). TopTools_ListIteratorOfListOfShape.hxx was removed as a standalone header in 8.0; the typedef now lives directly in TopTools_ListOfShape.hxx (already included), so the redundant include is dropped. Verified via a full local BinaryBuilder rebuild against OCCT 8.0.0 (from the not-yet-merged JuliaPackaging/Yggdrasil#14115) -- these two fixes were the only source changes needed across all ~44 binding files.
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.
Summary
V8_0_0_p1hotfix tag (latest non-prerelease release, commit4f95ecaa3b690e34988d42e2ca7fe882e7a8bc7d).src/OSD→src/FoundationClasses/TKernel/OSD,src/STEPConstruct→src/DataExchange/TKDESTEP/STEPConstruct), so all 6 bundled patches are retargeted to their new file paths.CMakeLists.txt.patch,OSD_signal.cxx.patch, andSTEPConstruct_AP203Context.cxx.patchalso needed context updates to match upstream changes (newVcpkginstall layout option,Standard_Boolean/Standard_False→bool/false, and a new FreeBSD-version-gated timezone code path — the cast fix now targets the remaining generic fallback branch).BUILD_MODULE_{Draw,Visualization,ApplicationFramework}CMake flags and alllibTK*toolkit product names were verified unchanged in 8.0 (toolkits just moved under new module folders).Test plan
patch -p1against the actualV8_0_0_p1source tree (dry run).BUILD_MODULE_*CMake option names and allproductstoolkit names against the upstream 8.0 source tree.🤖 Generated with Claude Code