Repository navigation
Main sync - #116
Merged
Merged
Main sync#116
Conversation
Fixed ASAN reports in `ipfs-pubsub` and `libp2p`
Fixed MNN and `wallet-core` warnings
…k-bootstrap compatibility
… self-referencing <INSTALL_DIR>)
…nned git submodules - shaderc pinned at v2024.3 (ff84893) — GLSL->SPIR-V compilation, matches Vulkan-1.3-targeting release line consistent with this project's pinned Vulkan-Headers/Loader ~1.3.302 - SPIRV-Tools pinned at 01c8438e — the exact commit shaderc's own DEPS file references for its v2024.3 tag (NOT shaderc main's current DEPS, which has since moved to a665e21f) — vendored as a separate, directly-linkable dependency so spvtools::SpirvTools::Validate() is callable without reaching into shaderc's internal, non-exported build tree - SPIRV-Headers pinned at 2a9b6f95 — same shaderc-v2024.3-DEPS-file cross-check, required transitive dependency of the standalone SPIRV-Tools build - shaderc's own nested glslang/spirv-tools/spirv-headers/etc. third_party/ deps are gclient-style (DEPS file + ./utils/git-sync-deps script), not git submodules, and are gitignored inside shaderc's own repo — populated via git-sync-deps for shaderc's own internal build, never committed anywhere
…d vendoring + IMPORTED targets Adds shaderc::shaderc and SPIRV-Tools::SPIRV-Tools CMake targets to CommonTargets.cmake, following the existing Vulkan-Headers/Vulkan-Loader/vk-bootstrap ExternalProject_Add convention, with the deviations a real local build+install spike confirmed are required: - SPIRV-Tools DOES install a CMake package config by default, but the exported target is the bare, non-namespaced SPIRV-Tools-static/-shared (the upstream SPIRV-Tools ALIAS is build-tree-only, never exported) -- resolved via find_package(SPIRV-Tools CONFIG) + an ALIAS to the project-controlled SPIRV-Tools::SPIRV-Tools name, with a hand-rolled IMPORTED fallback if the installed config is ever unavailable. - shaderc installs no CMake package config at all (confirmed via the same spike, matching github.com/google/shaderc/issues/1369 and github.com/microsoft/vcpkg/issues/23208) -- hand-written IMPORTED target against the confirmed-real installed libshaderc_combined.a. Verified via an actual local configure+build+install of all three ExternalProject_Add targets (MinGW GCC 13.2.0/Ninja, the toolchain available in this environment) plus a standalone consumer executable that links both shaderc::shaderc and SPIRV-Tools::SPIRV-Tools, compiles a trivial GLSL fragment shader to SPIR-V via shaderc, and validates the result via spvtools::SpirvTools::Validate() -- both targets configure, build, link, and the compile+ validate round-trip is functionally correct end-to-end.
…RTED targets The hand-written IMPORTED targets hardcoded .a extensions with a "lib" prefix (libshaderc_combined.a, libSPIRV-Tools.a) -- GCC/MinGW static-lib naming. Under this project's real MSVC/VS2022 generator the actual files are shaderc_combined.lib / SPIRV-Tools.lib (no prefix, .lib suffix), so the hardcoded path silently failed to find the built libraries. Switched to CMAKE_STATIC_LIBRARY_PREFIX/SUFFIX, which resolve correctly per toolchain. Confirmed by an actual rebuild against the real Windows/Release tree: shaderc_combined.lib and SPIRV-Tools.lib are found and linked. Also disables SPIRV-Tools' shared-lib build (BUILD_SHARED_LIBS:BOOL=OFF) since only the static targets are consumed.
…form-conditional Vulkan wiring - Move SPIRV-Headers, SPIRV-Tools, vk-bootstrap, shaderc ExternalProject_Add blocks and their IMPORTED targets outside if(NOT ANDROID) to unconditional scope - Keep Vulkan-Headers and Vulkan-Loader inside if(NOT ANDROID) (NDK provides on Android, MoltenVK on Apple) - Add _VK_BOOTSTRAP_VULKAN_HEADERS_DIR platform-conditional variable: desktop uses Vulkan-Loader prefix, Android/iOS build Vulkan-Headers from source - Replace hardcoded VulkanHeaders_DIR in vk-bootstrap with _VK_BOOTSTRAP_VULKAN_HEADERS_DIR - Verify SGShaderCompiler and SGProcessors link chains: no changes needed (all render targets already linked unconditionally)
…S Xcode - Document prerequisites: NDK r26+, Xcode 15+, CMake 3.22+, Python 3.7+ - Android build commands for arm64-v8a and armeabi-v7a ABIs - iOS build commands for arm64 device (PLATFORM=OS64, DEPLOYMENT_TARGET=15) - Expected static library outputs per platform - Link verification procedure via SuperGenius platform CMake configure - Troubleshooting: Python, ANDROID_STL, VulkanHeaders_DIR, memory, Xcode
…gPeersWithRetry (AsyncIOManager)
The reference bot commit ("updated references") moved MNN back to
84b4cac, which predates the MoltenVK framework linking fix, so the
iOS CI failed with undefined ObjC/Foundation/QuartzCore symbols when
linking MNN's LLM demos against libMoltenVK.a. Point MNN at the fork
tip, which additionally links UIKit (iOS) and the objc runtime.
Co-Authored-By: Claude <noreply@anthropic.com>
MNN a2b29259 adds the missing IF(MNN_BUILD_LLM) INSTALL rule to the ELSEIF(NOT APPLE) branch, so Linux/Android/Windows thirdparty builds ship MNN/llm/llm.hpp alongside libMNN.a (library already contained the Transformer symbols; only the header was dropped).
This reverts commit 13a0434.
- libp2p: Autonat detached threads no longer touch a destroyed instance (SIGSEGV in child_tokens_test on macOS Release). - ipfs-pubsub: batch flush timer can no longer wedge PublishBuffered(). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
- libp2p: Autonat joins its background threads (fixes shutdown crash). - ipfs-lite-cpp: graphsync sends requests synchronously again; keeps the block-attribution fix. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Pairs with the SuperGenius change that stops handing GraphsyncDAGSyncer itself to graphsync as the service it answers remote requests from. Without this bump a responder that lacks a block answers nothing and the requester waits out its full in-progress timeout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MNN's dlopen-wrapper mode (the default when MNN_USE_SYSTEM_LIB is off) compiles vulkan_wrapper.cpp with -DMNN_USE_LIB_WRAPPER, defining every vk* name as a global function-pointer VARIABLE -- data/STT_OBJECT symbols inside libMNN.a / MNN.lib. SGProcessors in SuperGenius calls the vk* API directly against the real Vulkan prototypes, so those data definitions collide with its direct call sites at link time: - armeabi-v7a: Thumb BL relocations (R_ARM_THM_CALL) require an STT_FUNC target; lld hard-errors with 'interworking not performed' - arm64-v8a: the same binding silently resolves direct calls to the address of the pointer table -- a latent crash on the shipped path - Windows: same silent data/function binding collision in MNN.lib Android now links the NDK's libvulkan.so stub (STT_FUNC exports, same runtime loader on device); Windows links the thirdparty-built Vulkan-Loader import library. Linux/iOS/OSX already passed MNN_USE_SYSTEM_LIB=ON via _MNN_EXTRA_PARAM, so all platforms are now consistent.
A publish whose strand wait expired still publishes, so it now reports errc::timed_out instead of PUBLISH_FAILED. Lets SuperGenius keep the transaction queued rather than failing it and demoting the node to SYNCING for a message that was delivered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merge rendering branch
…_PATH The default binary dir (<prefix>/src/shaderc-build) pushes spirv-tools' MSBuild .tlog paths to 272 chars on Windows, past the 260-char MAX_PATH limit on runners without OS long-path support (MSB3491, seen on SG-I9-WIN11 in PR #116). Build in <build>/scb instead (~250 chars worst case). Install tree and shaderc::shaderc target are unaffected. Co-Authored-By: Claude Code <noreply@anthropic.com>
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
4 participants
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.