Homebrew adds a folder of shims to some system utilities (the C/C++ compiler suite,
pkg-config, etc.) to ensure that the build environment is consistent. Sometimes, software likes to record the full path of the compiler that was used, and some even like to embed the entire output of
env into the program at some point during the build process.
To address this, I would start by digging through the library to see what exactly is being left in there:
strings /usr/local/opt/volk/lib/libvolk.2.3.dylib | grep shims
From there, it’s a matter of figuring out how that path is ending up in the library - sometimes it’s a result of the build system (e.g.
CC variable - which would point to the shim - somehow gets recorded in the build process). Some programs like to record what build flags were used, which often includes a full path to the “compiler” (in our case, the shim).
It can be tricky trying to remove the inclusion from the path - the goal is to get the build system to keep using the shim without recording the fact that it did in fact use the shim. Replacing/patching too early in the process can cause the Homebrew shim system to be bypassed altogether, which can, in some packages, lead to subtle bugs that will be hard to track down.
You can see some examples of how this issue has been resolved in