Change:
gerbil 0.18 in nixpkgs is compiled with , which prohibits gxc from producing static executables (. Obviously, in Nix, the final install dir cannot be known at compile time; the end result is that the temporary directory used during the derivation is used instead when linking . This obviously results in a linker error at runtime: Given that [glow-lang][glow-lang-deriv] appears to use (the Gerbil interpreter), it would appear that this defect is at least known to some maintainers; however, it does not appear to be documented. Steps to reproduce the behavior: a nix-shell or other config with installed the steps in gerbil's [prepare your project tutorial][hello-world-tutorial] to create a skeleton project to build the project to run the program compiled in step 3. The program should act as expected in the tutorial; that is, the program should exit due to an not-implemented error. Screenshots of terminal text aren't useful; appropriate output has been supplied elsewhere. This was only tested on , but based on symptoms all platforms are likely to be affected. Since the dir of the Gerbil runtime is on path in nix, usage of can be used to fixup builds on darwin by using rpath; of course, this should only be considered acceptable when unpackaged as packaged executables should always be linked by store path. Some level of fixup is possible in that context but ideally such fixup should be provided as a util in nixpkgs or made unnecessary. output on sample executable: Note that the is only interpreted at build time, and refers to the location of the current build context; as such, setting it to the nix store location of does not fix the problem and instead causes local package resolution to fail. Per , it appears this issue only affects macOS. appears to be the last to touch the package. N.B.: actual command run was as I am using the Determinate Systems Nix installer which does not set up . From for my configuration, I am using the above mentioned version (), since can't rely on channel info. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [hello-world-tut]: [glow-lang-deriv]: [gerbil-static-note]:
Thanks a lot for the bug report. It looks like the default is wrong in and we should be using whatever expands to, which looks like it works. any suggestion?
It ahould be doing that already.
there is no GERBIL_HOMEing going on, right?
Aha. The Nix packaging has improved between 0.18 and 0.18.1. There is no business in the current packaging, but maybe there was in 0.18? October is so far away, I don't remember. (But does, and it looks like the was already removed between 0.17 and 0.18, which should be the time we started supporting creating executables in Nix.) Can you try the latest 0.18.1 from nixpkgs ? It works for me and hopefully should work for you. Weird that it doesn't work for you in 0.18.
Wait, are you using or that depends on gerbil? The former would use its build location as the directory, but the latter should do the right thing.
Unless I'm missing something, 0.18.1 doesn't appear to be in nixpkgs master: (permalink to current rev: ) I'm using flakes rather than directly, but I've tried both having a with and in , and also the following flake using : The result of building this is the same, though:
You can set GERBIL_HOME as a workaround
Maybe put that in the recipe, it is there for such casea of rehoming. Maybe it is precisely the fix for nix.
Having manually overlaid gerbil 0.18.1, I tried setting but to no avail:
Oops, the v0.18.1 wasn't merged. Now it is.
works great for me, and no anywhere in sight. Can you try v0.18.1, and if the problem persists, can you give instructions sufficient to reproduce from a clean environment?
NB: definitely manages to create executables for me using the v0.18.1 package, and I strongly believe it used to with v0.18 already.
On further testing, the exact same flake builds correctly on aarch64-linux: It seems this issue is specific to building under macOS - I'll revise the report to reflect that.
A variant of your works for me, building executables without this nonsense. Are you sure your environment is clean? You shouldn't be exporting any , , or such variables.
Running with produces demonstrably the same results (attached at end). Note the env is clean enough that even has to be set. In addition, building derivations happens in isolation from the user environment and shouldn't be affected by any environment variables set as the nix builder sets up a clean environment.
OK, this looks macOS specific enough that it might not be a bug in Gerbil or its packaging itself, but in how Nix fails to do on macOS the equivalent of on Linux. Still sad, and something we might have to work around on macOS.
Maybe or some hack can help as a workaround, but we quite possibly need some magic linker flags to set the library path right when building and the binary on mac. I don't have access to a mac at this point. Can you help? Maybe can.
Hey, MacOS strips LDLIBRARYPATH, DYLDLIBRARYPATH and the like so just passing them in the environment is pointless as they are stripped. The correct thing is "So be cautious with DYLDLIBRARYPATH and friends. Even better is to pass an -rpath to ld along with a -L<library-pathfor building if needed." AKA magic linker flags. Apple's is not gnu's at all and cannot be. See: It actually makes sense security-wise but can be a real PITA. If you cannot link properly at build time and need to change the link paths you can use: installnametool - change dynamic shared library install names That can add/remove/change the rpaths. Here is a working binary and the lib bindings. No finesse needed, build script exactly the same as on linux. drewc-iMac:ecm-user drewc$ otool -L /usr/local/opt/gerbil-scheme/v0.18-47- (compatibility version 0.0.0, current version 0.0.0) /usr/local/opt/gerbil-scheme/v0.18-47- (compatibility version 0.0.0, current version 0.0.0) (compatibility version 1.0.0, current version 1.3.0) (compatibility version 0, current version 3.0.0) (compatibility version 3.0.0, current version 3.0.0) (compatibility version 0, current version 9.6.0) (compatibility version 1.0.0, current version 1319.100.3) HTH, --drewc On Mon, Dec 11, 2023 at 9:02 AM François-René Rideau <
you're the one with a Mac and Nix. Can you make a PR that uses one of solutions?
I'll see if I can find some time to apply workarounds this week.
Doing a bit more investigation, it seems that the soname of is this path; per [this hint in the stdenv platform docs][darwin-soname] it seems that it can be fixed by using to change the soname to the final path. I'm rebuilding gerbil now using the vendored builder to see if this fixes it; if it does I'll turn it into a proper PR. Edit: I've confirmed that fixing the soname of this way does indeed fix all build outputs from , by changing the script: This gives these results: If you're happy with this approach I'll open a PR with these changes. [darwin-soname]:

Discussion:
./install.sh (cd $out/bin ; ln -s ../gerbil/bin/* .) runHook postInstall <ins> '' + lib.optionalString stdenv.isDarwin '' libgerbil="$(realpath "$out/gerbil/lib/libgerbil.so")" install_name_tool -id "$libgerbil" "$libgerbil" </ins> ''; dontStrip = true;