FR: Add `LD_LIBRARY_PATH` to devShell

[tingerrr]

When developing Typst with the new lld fixes (related to the new default linker of Rust 1.90) we no longer seem to be able to run Typst within the devShell. You simply get:

target/debug/typst: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

I'm actually unsure why we could even run it in the devShell before without explicitly setting LD_LIBRARY_PATH, I was under the impression that the runtime library path was only set for the built package, not the devShell. Regardless of that, not being able to run the program you're building in the devShell is kind of annoying.

Is adding LD_LIBRARY_PATH the idiomatic way to fix this, or is there a better solution? Ironically, I'm asking to fix my own flake for Tytanic where I'm preparing the MSRV bump to 1.91 ahead of time and that is where my tests stop failing (with a flake almost identical to this one before the move), so I tried it with Typst and this flake and ran into the same issue.

[PgBiel]

Problem is that we are downloading rustc directly from upstream, which doesn't know about Nix's stuff and uses its own linker (lld). We add the following env var while compiling with cargo, you will need to do the same to your shell:

typst-flake/flake.nix

Lines 94 to 101 in ec2389e

	env = {
	RUSTFLAGS =
	if pkgs.stdenv.hostPlatform.rust.rustcTargetSpec == "x86_64-unknown-linux-gnu" then
	# Upstream defaults to lld on x86_64-unknown-linux-gnu, we need to use the system linker
	"-Clinker-features=-lld -Clink-self-contained=-linker"
	else
	null;
	};

The advantage is that this will use everything from Nix, with your proposed env var we'd have to update it each time a new system dep is added.

I suppose we can consider adding this to the default dev shell as well (feel free to PR).

Though I guess ld_library_path is not that bad either for dev shell.

[tingerrr]

If the RUSTFLAGS are less maintenance, then that is what we should add in, in my opinion. LD_LIBRARY_PATH is just the first thing that came to mind, which is why I asked for a better alternative too. I'll try this locally and create a PR.