forked from lix-project/lix
Artemis Tosini
19de2b137f
Add basic support for building and linking Rust into libutil.
This also includes a basic test to show that the linking is successful.
This test should be removed once a more practical use for the Rust has
been found, as testing those would necessarily require linking to work.
--- 👻 jade haunting section 👻 ---
This uses a very cursed approach to ensure that static builds do not
invoke undefined behaviour caused by linking libstd and friends multiple
times. That is, for static targets, we just statically link the whole
thing into the executable, and for dynamic targets we dynamically link
all the Rust stuff.
Reference re this being ostensibly illegal: https://github.com/rust-lang/rust/issues/44322
Even if it does not cause linker errors, it is not a *good idea* to link
a Rust staticlib containing libstd into multiple C++ dylibs to be loaded
into the same executable, since it is highly unclear whether libstd
globals would be correctly shared (and stuff like -Bdynamic ever getting
into link args can absolutely murder you by changing *intra-dylib*
references to not indirect through the PLT (and thus ignore any other
loaded dylib containing the symbol) underneath your nose).
This means that a solution of liblixutil_rs, liblixcmd_rs, etc, that are
statically linked into liblixutil, liblixcmd, etc *is not safe*.
Effectively `libstd` *must* be in its own dylib in an environment
containing dynamic linking of multiple bits of Rust code.
The reason that we shouldn't just jam all the Rust in one staticlib for
shared targets as well (though I::jade can still be convinced we
*should* do it for those), is that we would have to build a
liblixrust.so that depends on *every* other Lix library, **and** every
other Lix library depends on it, exploding our dylib hierarchy
completely to uselessness.
Building a libfirefoxrust.a and then linking it in *is* what Firefox
does, but it does not work for us since our system is not one big
library/etc. It would probably have perf benefits, but so would getting
rid of dynamic linking completely.
Meson bugs encountered (for github xref to find):
Meson does not set the soname for us: https://github.com/mesonbuild/meson/issues/13537
Meson ignores link_args for Rust targets: https://github.com/mesonbuild/meson/issues/13538
Co-authored-by: Qyriad <qyriad@qyriad.me>
Co-authored-by: Jade Lovelace <lix@jade.fyi>
Change-Id:
|
||
|---|---|---|
| .github | ||
| bench | ||
| contrib | ||
| doc | ||
| maintainers | ||
| meson | ||
| misc | ||
| nix-support | ||
| perl | ||
| releng | ||
| scripts | ||
| src | ||
| subprojects | ||
| tests | ||
| .clang-format | ||
| .clang-tidy | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .envrc | ||
| .gitignore | ||
| .this-is-lix | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| default.nix | ||
| docker.nix | ||
| flake.lock | ||
| flake.nix | ||
| justfile | ||
| meson.build | ||
| meson.options | ||
| package.nix | ||
| README.md | ||
| shell.nix | ||
| treefmt.toml | ||
| version.json | ||
Lix
Lix is an implementation of Nix, a powerful package management system for Linux and other Unix systems that makes package management reliable and reproducible.
Read more about us at https://lix.systems.
Installation
On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
For systems that already have a Nix implementation installed, such as NixOS systems, read our install page
Building And Developing
See our Hacking guide in our manual for instruction on how to to set up a development environment and build Lix from source.
Additional Resources
License
Lix is released under LGPL-2.1-or-later.