Repository navigation
Conversation
RocksDB 6.29.fb and its zlib/bzip2/lz4/zstd/snappy dependencies are built from source with PORTABLE=1, mirroring upstream's own docker/build-*.sh. PORTABLE=1 disables every x86-only compiler probe in rocksdb's build_detect_platform, and util/crc32c.cc's hardware CRC32 paths are all gated on HAVE_SSE42/HAVE_ARM64_CRC/HAVE_POWER8, none of which get defined on riscv64, so it falls back to the portable table-based implementation upstream already ships non-x86 (aarch64) wheels with.
All four manylinux_riscv64 matrix legs failed identically at the same step: rocksdb 6.29.fb's db/db_impl/db_impl.cc fails to compile under manylinux_2_39_riscv64's GCC 14.3.1 with `error: redundant move in return statement [-Werror=redundant-move]` on `return std::move(io_s);`. The code predates this diagnostic; upstream's own (older) build image never hits it. rocksdb's Makefile already gates -Werror behind `ifndef DISABLE_WARNING_AS_ERROR`, so pass DISABLE_WARNING_AS_ERROR=1 to the shared_lib build instead of patching or disabling warnings project-wide.
|
All four matrix legs (cp312/cp313/cp314/cp314t) failed identically, in the same build step, at the same source line — confirming a single shared root cause rather than per-interpreter issues. Root cause: rocksdb 6.29.fb (2021-era code) wasn't written against a GCC strict enough to flag this NRVO-eligible Fix: rocksdb's Makefile already has a purpose-built escape hatch for exactly this ( |
Force-include <cstdint> for rocksdb: GCC 14's libstdc++ no longer pulls it in transitively and table/block_based/data_block_hash_index.h needs uint8_t/uint16_t/uint32_t. Pass PPC_LIBC_IS_GNU=0 so rocksdb's Makefile leaves out the optional range-lock manager, whose toku_time.h has no riscv64 timer and stops with '#error No timer implementation for this platform'. aimrocks does not use TransactionDB or NewRangeLockManager.
cmake's GNUInstallDirs module defaults the install libdir to lib64 for a 64-bit build on this manylinux_2_39_riscv64 (RHEL-family) image, so snappy's cmake install was putting libsnappy.a in /opt/deps/lib64 while zlib/bzip2/lz4/zstd's plain Makefiles install into /opt/deps/lib. rocksdb's shared_lib link step only sets LIBRARY_PATH=/opt/deps/lib, so the linker couldn't find it: /usr/bin/ld: cannot find -lsnappy: No such file or directory identical across all four matrix legs (cp312/cp313/cp314/cp314t), since none of them reach the link step with a different environment. Pin snappy's cmake configure to -DCMAKE_INSTALL_LIBDIR=lib so it installs next to the other codecs.
aimrocks0.5.2Cython RocksDB binding; compiles RocksDB 6.29.fb and its zlib/bzip2/lz4/zstd/snappy dependencies from source. Upstream publishes no riscv64 wheel.
Mirrors the
deps/rocksdb/wheelsstages of upstream'sDockerfileand thedocker/build-*.shscripts they run.Differs from upstream
tests/suite - upstream's packaging pipeline only builds wheels, never tests themTesting
tests/suite (see above)License: Wheel bundles rocksdb (Apache-2.0), zlib, bzip2, lz4, zstd and snappy (all permissive, none GPL); upstream ships no license text for them, so the build adds it.
Built on cp312; CI pending.