Conversation
a0d34cc switched HCParser::SetScriptDir to m_file_handler.SetReferenceDirectory(dir). That member exists on Chrono main, but not on the Chrono 10.0.0 release that SEA-Stack documents as its baseline, so the app fails to compile against 10.0.0. Restore the protected m_script_directory assignment, which is the Chrono 10.0.0 API. The yaml-cpp half of a0d34cc is kept unchanged -- preferring Chrono::yaml-cpp over a system yaml-cpp is correct on both Chrono versions and avoids the YAML::FpToString / YAML::Emitter::Write link errors Salhus reported. Verified on Ubuntu 22.04 against Chrono 10.0.0 built with Chrono's pinned VSG stack (vsg 1.1.11, vsgXchange 1.1.7, vsgImGui 0.7.0).
…Sorted crash" This reverts 2172d0b, restoring the intended translucent free surface (kWaterOpacity = 0.55) and the faint translucent wireframe overlay (SetOpacity(0.35)). The DepthSorted / vsg::Bin::add crash does not reproduce against the documented Chrono 10.0.0 baseline. Chrono 10.0.0 has no wrapIfTransparent() helper and does not wrap runtime-added nodes in vsg::DepthSorted, so a sub-1.0 material opacity never reaches the bin-10 path described in 2172d0b. That code was added on Chrono main after the 10.0.0 release, which is the most likely reason the crash was seen. Validated on Ubuntu 22.04.5 + RTX 3060 against Chrono 10.0.0 built with Chrono's pinned VSG stack (vsg 1.1.11, vsgXchange 1.1.7, vsgImGui 0.7.0, glslang 15.4.0): the 5SA bimodal GUI runs with translucent water and the wireframe toggle without any FATAL or renderer crash. Please retest on your Linux machine against Chrono 10.0.0 specifically. If the crash returns there, the VSG stack version is the thing to compare first, and we should fix the runtime compile traversal rather than force opacity to 1.0.
On Ubuntu, scripts/unix/build.sh treated an empty HDF5Dir in build-config.json as "HDF5 missing" and forced SEASTACK_ENABLE_HYDRO_IO=OFF. CMake was therefore never given a chance to find the apt libhdf5-dev package, and builds that did want HydroIO failed later on a missing h5_reader.h rather than at configure time. The only workaround was an undocumented manual HDF5Dir entry. Two small changes: * scripts/unix/build.sh - leave HydroIO ON when HDF5Dir is unset and print an INFO note instead. CMake's FindHDF5 then runs normally, and a genuinely missing HDF5 fails at configure time with a clear error. * CMakeLists.txt - Chrono's ChronoConfig can leave HDF5_DIR cached as NOTFOUND when Chrono itself found HDF5 via module mode. Clear that stale value, then probe module-mode find_package(HDF5 COMPONENTS CXX) when HydroIO is enabled and HDF5 is not yet found. Validated on Ubuntu 22.04.5 with "HDF5Dir": "" and Chrono 10.0.0 + VSG: configure reports HydroIO ON, libseastack_hydro_io.a builds, and run_seastack links libhdf5_serial 1.10.7 via module mode while HDF5_DIR stays NOTFOUND.
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
1 participant
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.
Follow-up changes from testing PR #7 on Ubuntu 22.04 against SEA-Stack’s documented Chrono 10.0.0 baseline.
This adds three targeted changes on top of salhus/linux-support-fixes:
Tested locally on Ubuntu 22.04 with Chrono 10.0.0:
@salhus - could you please retest this combined branch on your Linux setup using Chrono 10.0.0? It would also be useful to know which Chrono version/commit you originally tested PR #7 against, as a couple of the original changes appear to target a newer Chrono main API.