445b596238
The linux-amd64 release build was intermittently failing with:
'asm' operand has impossible constraints
in secp256k1's hand-written x86_64 assembly (scalar_4x64_impl.h,
USE_ASM_X86_64 path). Root cause, confirmed against upstream
(bitcoin-core/secp256k1#1623): on GCC 11 (Ubuntu 22.04's default),
-march=native's CPU autodetection misidentifies early AMD Zen4 chips
as znver3 while still enabling -mavx512f via CPUID feature probing.
-march=znver3 -mavx512f is an invalid combination matching no real
CPU -- GCC 11 predates Zen4 entirely -- and its register allocator
cannot satisfy the asm's constraints under it. Upstream confirmed
this is fixed by a GCC version that knows about znver4 (13+), and
closed the report as a GCC autodetection bug, not a secp256k1 defect.
This explains the apparent intermittency: it only reproduces on
whichever physical Zen4 host GitHub's runner fleet happens to assign
to a given job.
Two independent changes address this:
- Bump the linux-amd64 and linux-arm64 release builders from
ubuntu-22.04(-arm) to ubuntu-24.04(-arm), kept on the same Ubuntu
version across both architectures. Ubuntu 24.04 ships GCC 13 by
default (GCC isn't installed separately in this workflow -- the
runner image's preinstalled toolchain comes from its Ubuntu base),
which correctly recognizes znver4 and produces a valid -march=native
expansion.
- Also pass -d:disableMarchNative on the linux-amd64 build (matrix-
scoped; arm64/macOS don't compile the affected x86_64 asm path).
This is kept even after the GCC bump because -march=native is
independently unsound for a publicly distributed binary: it bakes
in whatever instruction set extensions the build runner's CPU
happens to have (e.g. AVX-512) into the shipped binary, which would
crash with an illegal instruction on end-user machines lacking that
extension -- a separate, permanent concern from the GCC 11 bug.
Logos Storage Filesharing Client
The Logos Storage project aims to create a filesharing client that allows sharing data privately in p2p networks.
WARNING: This project is under active development and is considered pre-alpha.
Build and Run
To build the project, clone it and run:
make update && make
# Tip: use -j{ncpu} to for parallel execution, eg:
# make -j12 update && make -j12
The executable will be placed under the build directory under the project root.
Run the client with:
build/storage
Configuration
It is possible to configure a Logos Storage node in several ways:
- CLI options
- Environment variables
- Configuration file
The order of priority is the same as above: CLI options --> Environment variables --> Configuration file.
Please check build/storage --help for more information.
API
The client exposes a REST API that can be used to interact with the clients. Overview of the API can be found on api.codex.storage.
Bindings
Logos Storage provides a C API that can be wrapped by other languages. The C API bindings are located in the library folder.
Currently, only Go bindings are provided in this repo. However, Rust bindings for Logos Storage can be found at https://github.com/nipsysdev/storage-rust-bindings.
Build the C library
make libstorage
This produces the shared library under build/.
Run the Go example
See https://github.com/logos-storage/logos-storage-go-bindings-example.
Static vs Dynamic build
By default, Logos Storage builds a dynamic library (libstorage.so/libstorage.dylib/libstroage.dll), which you can load at runtime.
If you prefer a static library (libstorage.a), set the STATIC flag:
# Build dynamic (default)
make libstorage
# Build static
make STATIC=1 libstorage
Limitation
Callbacks must be fast and non-blocking; otherwise, the working thread will hang and prevent other requests from being processed.
Contributing and development
Feel free to dive in, contributions are welcomed! Open an issue or submit PRs.
Linting and formatting
logos-storage-nim uses nph for formatting our code and it is required to adhere to its styling.
If you are setting up fresh setup, in order to get nph run make build-nph.
In order to format files run make nph/<file/folder you want to format>.
If you want you can install Git pre-commit hook using make install-nph-commit, which will format modified files prior committing them.
If you are using VSCode and the NimLang extension you can enable "Format On Save" (eq. the nim.formatOnSave property) that will format the files using nph.