Change:
Describe the bug is a language that can be compiled to many targets. It has scripts that will do this for you, like faust2alsa, which will generate a alsa program with a GTK ui, or faust2alqt, which will generate an alsa + QT one. Some of those will work as expected, others only inside a nix-shell. To Reproduce Steps to reproduce the behavior: /tmp && touch && echo 'process=+;' -env -iA nixos.faust2alqt 2alqt Working version: /tmp && touch && echo 'process=+;' -env -iA nixos.faust2alqt -shell $NIXPKGS -A magnetophonDSP.faustCompressors 2alqt ./tst Additional context All faust scripts used to work up until . I've created this new issue cause the old one only mentioned faust2lv2 and could be worded clearer. To test in a normal shell: To test in nix-shell, use this working in normal shell faust2csound faust2firefox faust2jack faust2ladspa only working in nix-shell faust2alqt faust2jaqt faust2lv2 working in neither faust2alsa The ones that only work in nix-shell claim they are missing dependencies when used in the normal shell, for example this one from faust2alqt: I'll spare you the errors for the other examples, as I assume they all have the same root cause. Let me know if I should provide them anyway. ` is a wrapped shell-script. I tried to debug by adding some relevant echo statements to it, echoing the exact gcc command being called, and echoing env | grep boost. It outputs the exact same thing if I run it from normal shell or nix-shell. I also tried reverting the last few faust commits and rebuilding from there. No dice. It would be great to figure out why some only work in nix-shell and even better to fix it! Hints how to troubleshoot further are greatly appreciated. In my upcoming PR for a faust update, at least none of the scripts are broken in both shells. Metadata system: host os: multi-user?: sandbox: version: channels(bart): channels(root): nixpkgs: Maintainer information:
Would you mind taking a look?
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
still important to me
I marked this as stale due to inactivity. &rarr;
I believe this is a fix; are you able to test this? I successfully compiled your example with . (or my branch here )
Thank you :100: times! Everything works as expected! Do you want to do a PR, or shall I?

Discussion:
# export parts of the build environment for script in "$out"/bin/*; do <ins> # e.g. NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu nix_cc_wrapper_target_host="$(printenv | grep ^NIX_CC_WRAPPER_TARGET_HOST | sed 's/=.*//')" # e.g. NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu nix_bintools_wrapper_target_host="$(printenv | grep ^NIX_BINTOOLS_WRAPPER_TARGET_HOST | sed 's/=.*//')" </ins> wrapProgram "$script"  --set FAUSTLDDIR "${faust}/lib"  --set FAUSTLIB "${faust}/share/faust" 

--prefix PKG_CONFIG_PATH : "$PKG_CONFIG_PATH"  --set NIX_CFLAGS_COMPILE "$NIX_CFLAGS_COMPILE"  --set NIX_LDFLAGS "$NIX_LDFLAGS -lpthread"  <del> --prefix LIBRARY_PATH $libPath </del> <ins> --set "$nix_cc_wrapper_target_host" "''${!nix_cc_wrapper_target_host}"  --set "$nix_bintools_wrapper_target_host" "''${!nix_bintools_wrapper_target_host}"  --prefix LIBRARY_PATH "$libPath" </ins> done ''; });