lorri
patchelf
lorri | patchelf | |
---|---|---|
6 | 12 | |
998 | 3,248 | |
- | 2.2% | |
0.0 | 3.6 | |
almost 2 years ago | 23 days ago | |
Rust | C | |
Apache License 2.0 | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lorri
-
NixOS + Haskell best practices circa March 2023
lorri
- Lorri: Project's Nix-Env
-
niv, naersk, napalm: moving on
And how does niv compare to https://github.com/target/lorri
-
A treatise on Nix
Yes, you can "hold on", it's called gcroots. There's lorri which you can also use to defer the tediousness of managing the gcroots to a daemon.
-
Per process memory and CPU usage control
Not that I know of but if you are having trouble with rebuilding and running out of memory, maybe the solution would be to cache the builds locally? You could use lorri to cache your development builds (https://github.com/target/lorri).
-
NixOS Linux
> Using a special command (nix-shell) whenever I needed to do development things (e.g. Rust builds) was not my idea of fun.
Funny you should mention that, because that's exactly what got me using Nix everywhere :). I've always hated installing tools and libraries globally—what if I need a different version for a future project?—so I like tools that sandbox as much as possible like virtualenv, cargo, cabal... etc. But these tools are all language-specific and have their own limitations (especially around native libraries and dependencies written in other languages).
nix-shell gives me the equivalent of virtualenv that works for everything. I can have a single sandboxed environment even if my project uses a bunch of different languages and I can manage everything in a reproducible, low-overhead fashion. No more worrying about making a mess by installing tools or packages globally.
Then, once I got really used to that, I spent some time setting up direnv[1] and lorri[2]—both of which are themselves managed with Nix, of course!—so that my environment gets automatically configured as soon as I enter a project directory without needing to call nix-shell explicitly. To be honest, the experience is still a bit rough, but it works well enough day-to-day that I have my reproducible sandbox cake and eat it in an mostly frictionless way too :).
[1]: https://direnv.net/
[2]: https://github.com/target/lorri
patchelf
-
Debian pauses /usr merge file moves
I mean, we don't have to hack the elf loader if we just rewrite every elf binary using patchelf: https://github.com/NixOS/patchelf
The parent commenter is already suggesting "just run a regex", so it seems like a trivial extension to their simple solution to "just run patchelf on every binary on your system"
-
How does Nix make sure binaries can access their runtime dependencies?
Patching paths in text files typically used substituteInPlace (including in cowsay). For dynamic libraries, patchelf is typically used.
-
"Discord installation is corrupt" on Ubuntu Linux.
Install patchelf.
-
Invalid or corrupted package (PGP signature)
Thank you! I followed the instruction here, but it looks like I didn't actually install it, because my pacman -Q patchelf did not find anything. Maybe I was missing a dependency. Also, it was late so I didn't pay attention to warnings at the time.
-
Rpath, or why lld doesn’t work on NixOS
How does an article on NixOS talk about the `rpath` issue without also mentioning the `patchelf` utility that NixOS developers created to solve this issue? It's a small tool that lets you modify ELF executables and binaries. It's also the recommended way for NixOS users to modify binaries to work properly.
https://github.com/NixOS/patchelf
-
cxfreeze error when compiling py to exe
So install it? https://github.com/NixOS/patchelf
- PatchELF: Simple utility for modifying existing ELF executables and libraries
-
Scala project (FIRRTL) failing to build on NixOS
NixOS doesn't have stable paths to shared libraries like macOS or other linux distributions (and this is the core feature) and always need to patch elf for current paths ( https://github.com/NixOS/patchelf ).
What are some alternatives?
direnv - unclutter your .profile
nixops - NixOps is a tool for deploying to NixOS machines in a network or cloud.
nix - Nix, the purely functional package manager
vscode-remote-release - Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
nix-direnv - A fast, persistent use_nix/use_flake implementation for direnv [maintainer=@Mic92 / @bbenne10]
serverless-application-model - The AWS Serverless Application Model (AWS SAM) transform is a AWS CloudFormation macro that transforms SAM templates into CloudFormation templates.
nixpkgs - Nix Packages collection & NixOS
nickel - Better configuration for less
libelfin - C++11 ELF/DWARF parser
dotfiles - i3 + Plasma: using the i3 window manager on the top of KDE Plasma and other dotfiles, configurations, scripts, workarounds and practises from my Debian Sid machines.
eresi - The ERESI Reverse Engineering Software Interface