Use buildFHSUserEnv to support on-demand downloaded binaries?

[shazow]

Something like https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/embedded/arduino/arduino-cli/default.nix#L40

[andrevmatos]

Yes, solc download is missing without this one. Anyone knows a workaround?

[shazow]

I don't have a good fix for bundling solc with foundry, but there was a NixOS fix upstreamed to the foundry solc autodownloader, so (at least for me) it patches the solc binaries properly now?

[andrevmatos]

Yes, looking more closely, https://github.com/roynalnaruto/svm-rs/pull/48 does patch binaries on NixOS, but they hardcoded to do that only for solc>=0.8, but our codebase is pulling solc 0.7.6, which was a later patch release in the 0.7 series which happens to also be dynamically linked, and this is making the whole process trip balls; weird thing is, even if I patch manually in ~/.svm, it still try to download the same version again, and fail when trying to validate it. More of a svm-rs issue then

[bohendo]

I'm scratching my head over what must be a related issue:

$ uname -a
Linux system76 5.15.80 #1-NixOS SMP Sat Nov 26 08:24:52 UTC 2022 x86_64 GNU/Linux

$ forge build
[⠊] Compiling...
[⠃] Installing solc version 0.7.6
[⠊] Successfully installed solc 0.7.6
[⠃] Installing solc version 0.7.6
[⠊] Successfully installed solc 0.7.6
Error: 
"/home/bohendo/.svm/0.7.6/solc-0.7.6": No such file or directory (os error 2)

$ ls -l /home/bohendo/.svm/0.7.6/solc-0.7.6
-rwxrwxrwx 1 bohendo users 11260472 May 13 15:49 /home/bohendo/.svm/0.7.6/solc-0.7.6

$ file /home/bohendo/.svm/0.7.6/solc-0.7.6
/home/bohendo/.svm/0.7.6/solc-0.7.6: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=2636f404338a79ce71e1aad876a0c81db2a79ec0, stripped

$ ldd /home/bohendo/.svm/0.7.6/solc-0.7.6
	linux-vdso.so.1 (0x00007fff2bb17000)
	libdl.so.2 => /nix/store/4nlgxhb09sdr51nc9hdm8az5b08vzkgx-glibc-2.35-163/lib/libdl.so.2 (0x00007f630d572000)
	libm.so.6 => /nix/store/4nlgxhb09sdr51nc9hdm8az5b08vzkgx-glibc-2.35-163/lib/libm.so.6 (0x00007f630d492000)
	libc.so.6 => /nix/store/4nlgxhb09sdr51nc9hdm8az5b08vzkgx-glibc-2.35-163/lib/libc.so.6 (0x00007f630d289000)
	/lib64/ld-linux-x86-64.so.2 => /nix/store/4nlgxhb09sdr51nc9hdm8az5b08vzkgx-glibc-2.35-163/lib64/ld-linux-x86-64.so.2 (0x00007f630e043000)

$ /home/bohendo/.svm/0.7.6/solc-0.7.6
bash: /home/bohendo/.svm/0.7.6/solc-0.7.6: No such file or directory

$ strace /home/bohendo/.svm/0.7.6/solc-0.7.6 
execve("/home/bohendo/.svm/0.7.6/solc-0.7.6", ["/home/bohendo/.svm/0.7.6/solc-0."...], 0x7ffeb283c0c0 /* 152 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

I'm bewildered by this "no such file" error, if it was improperly linked or incorrect checksum I'd expect an error along those lines, but this file definitely does exist..?

Does this solc executable even need to be patched? ldd suggests it's wired up properly. Why is solc 0.7.6 being downloaded twice? Is this an issue that should be opened up against svm-rs instead or do we think the problem was introduced during nixification?

Thanks in advance if anyone can help me out here. :grin:

[shazow]

@bohendo Any chance your ~/.svm dir has some stale unpatched binaries from before? Try deleting that dir and trying again, I've found that recent versions of svm-rs are nix-aware (make sure you're using a recent version of foundry.nix, too).

[bohendo]

I did nix flake update against the input foundry.url = "github:shazow/foundry.nix/monthly"; so I assume I'll be using a recent svm-rs but foundry-bin doesn't seem to include svm directly so not sure how to confirm this..

I ran rm -rf ~/.svm to reset compilers & re-ran forge build but got the same result.

What's the best way to add svm to my devShells directly? Might be good to target future debugging efforts directly against that.

[andrevmatos]

Yes, solc 0.7.6 is a pain. I've PR'd https://github.com/roynalnaruto/svm-rs/pull/82 exactly to include it in svm's patching. Not sure why ldd doesn't show it, but somehow one of the versions downloaded at runtime by svm-rs isn't patched until my PR get's pulled in foundry. No easy workaround, even if you patchelf it locally, svm still insists in downloading the unpatched version every time. Bump solc to v0.8 to avoid the issue, if you can.

[hellwolf]

Yes, looking more closely, alloy-rs/svm-rs#48 does patch binaries on NixOS, but they hardcoded to do that only for solc>=0.8, but our codebase is pulling solc 0.7.6, which was a later patch release in the 0.7 series which happens to also be dynamically linked, and this is making the whole process trip balls; weird thing is, even if I patch manually in ~/.svm, it still try to download the same version again, and fail when trying to validate it. More of a svm-rs issue then

The workaround of it is to add specific solc_version in foundry.toml.

$ grep solc_version  foundry.toml 
solc_version = "0.8.19"

I can send a PR in README of this project so that more people can know about this. But I don't really understand why this has to be a workaround, it seems some bug in foundry itself if anyone wants to investigate more.

Furthermore, I have a assorted solc collection flake if anyone wants a specific version of solc for their project outside the foundry tooling: https://github.com/hellwolf/solc.nix/

[shazow]

@hellwolf That's handy, thanks! Improvements to the README are always appreciated. :)