we have the patch already and i dont want to make it nix
exclusive by reverting it in my rocksdb fork
Signed-off-by: strawberry <strawberry@puppygock.gay>
The original implementation of this was really weird, so I restructed it
a lot while debugging, and am just gonna leave the restructured version.
Root cause of the segfault seems to be that upstream nixpkgs liburing
derivation is generating both static and dynamic libraries, causing
rocksdb to statically link liburing in a dynamic build, pulling in some
allocator stuff at the same time. I created a PR[1] to fix this upstream,
but it probably won't be available on nixos-unstable for quite a while,
so we can also patch it locally.
[1]: https://github.com/NixOS/nixpkgs/pull/314945
This failed to inherit the fix from bec507d7390dda9ca2e624ef846521a20e2252c7
because the crane package's buildInputs become propagatedBuildInputs in
a static stdenv, but become normal buildInputs in a dynamic stdenv. Since
we were only pulling propagatedBuildInputs into the devshell, dynamically
linked devshells did not include the rust-jemalloc-sys package. This
causes tikv-jemalloc-sys to build it's own static jemalloc package, and
we end up loading libc before jemalloc at runtime.
Previously we were relying on NIX_CFLAGS_COMPILE, but this is not being
set in static devshells. A cleaner solution for complement would likely
be to build the tests in their own nix derivation instead of building
them in the devshell, but this change unblocks CI for now.
CI is running `cargo build --all-features`, so we should be passing all
the features to nix as well.
The only thing this currently affects is the jemalloc_prof feature, but if
we add any non-default features that affect nix in the future they should
also be handled correctly now.
Dynamically-linked jemalloc doesn't work due to link-order issues, and we
want CI to be testing a static binary anyway since that's what we're
publishing in releases.
Without setting JEMALLOC_OVERRIDE, we end up linking to two different
jemalloc builds. Once dynamically, as a transitive dependency through
rocksdb, and a second time to the static jemalloc that tikv-jemalloc-sys
builds.
there's really no point in trying to stay as low as possible for us,
and this makes development easier. Debian users should just use rustup,
Nix users already get the proper toolchains.
Signed-off-by: strawberry <strawberry@puppygock.gay>
Apparently github actions VMs ship with it and that's how it was working
before? Cursed. We should control our own supply chain and also ensure
that local development uses the same version as CI.
Some of the improvements here include:
* rocksdb can actually use jemalloc now instead of just pulling in a
second rocksdb for no reason
* "complement-runtime" factored back out into shell file
* complement image no longer uses `mkDerivation` for `copyToRoot`
because that's what `buildEnv` is for
* complement image no longer sets `SERVER_NAME`, complement already does
that
* all packages were factored out into `callPackage`-able files for use
with a custom `lib.makeScope pkgs.newScope`
* new version of `mkPackage` has options that are easier to use and
override such as `features`
