NixOS JVM | 122 Members | |
| 26 Servers |
| Sender | Message | Time |
|---|---|---|
| 14 Jul 2025 | ||
| * Does anyone on this list have the ability to merge PR #421362 (above) ? It's a straightforward version bump and has 2 approvals. Update: it's been merged! | 15:54:14 | |
| i think i don't need to use a flake, i'm going to focus on working with nix-shell and ensuring LD_LIBRARY_PATH is path. | 15:58:35 | |
Can you describe the big picture of what you are trying to do? Why do you want to use nix-ld? I have used a C library from Java in Flake-based dev shell, but it was already in Nixpkgs. I have not used nix-ld before and just now read what it is. Can you describe your use case a little? | 16:03:13 | |
| of course! i'm working on a codebase that is written in Java, and that requires me to install JVM and gradle as you know. But this project when running needs to dynamically load a libGL library. However when it does it can't seem to locate it. I believe that if LD_LIBRARY_PATH is set, it should be able to find it | 16:36:39 | |
| nix-ld seems to be a way to draw in from external libraries for compiling a package? I need to spend more time wrapping my head around it | 16:37:13 | |
just add autoAddDriverRunpath to nativeBuildInputs | 16:40:36 | |
the path to our libGL will be patched in to the built binary automatically | 16:40:44 | |
| (if you are building inside Nix) | 16:40:49 | |
nix-ld is really only there for running awkward third-party binaries | 16:41:01 | |
| ahh thank you for that! hmm | 16:41:42 | |
if you're doing interactive development, then you should be able to just set LD_LIBRARY_PATH to include the path in your development shell hook | 16:41:51 | |
| i don't think i'm building inside of nix, i'm using the command line tools for running gradle inside of the project repository which i think is part of why it's not finding everything | 16:42:55 | |
e.g. export LD_LIBRARY_PATH=${addDriverRunpath.driverLink} | 16:42:56 | |
| ahh i see. okay! i'm going to do that. thanks! | 16:43:32 | |
$LD_LIBRARY_PATH will be used at runtime so it works inside a shell even with a binary that doesn't get the path patched in, and autoAddDriverRunpath would handle baking it in if you want a package built in Nix to install systemwide etc. | 16:44:30 | |
| Thanks @emily. I've been using a hackier solution. Is this documented somewhere? | 16:45:19 | |
| umm, good question :) if it is, I don't know about it because of the documentation | 16:46:05 | |
| the answer is, uh, it's mentioned in passing in the documentation for CUDA maintenance! | 16:46:54 | |
| and some release notes | 16:47:02 | |
| it's usually only relevant for third-party binaries | 16:47:43 | |
since "normal" software just links directly to libGL | 16:47:49 | |
but stuff doing dlopen at runtime needs LD_LIBRARY_PATH/runpath fixups | 16:48:12 | |
also, I said autoAddDriverRunpath but it probably wouldn't work for Java programs you're not building into a native executable with Graal or something because of course you just end up with a .jar and some shell scripts around it… | 16:48:43 | |
you would probably actually want to makeWrapper … --prefix LD_LIBRARY_PATH : ${addDriverRunpath.driverLink}/lib instead | 16:49:22 | |
also this is missing a /lib, sorry :) | 16:49:27 | |
| :) | 16:49:55 | |
Well that's for making a Nix package or deploying, right? If softmoonworld is (perhaps initially) only interested in development, there should be a way to add it via Gradle. My hacky solution added the library via
| 16:55:32 | |
*
Well that's for making a Nix package or deploying, right? If softmoonworld is (perhaps initially) only interested in development, there should be a way to add it via Gradle. My hacky solution added the library via
| 16:55:59 | |
| My hacky GitLab CI build is like this:
| 16:59:09 | |
So I'm hoping autoAddDriverRunpath might allow me to get rid of the nix profile install | 16:59:45 | |