Hello,
We use Spack to build our HPC software stack. Recently we have been using a new feature that inserts a = in paths to libraries. When attempting to link with these libraries using absolute paths, we often see warnings along the line:
nvc++-Warning-unknown driver variable assigned on the command line: /long/path/libsonata-report-git.b767078972c375408faee8f348b794039a994493=develop-oerirz/lib/libsonatareport.so
followed by errors about missing symbols.
The shortest similar reproducer I came up with is:
❯ nvc++ a=b.c++
nvc++-Warning-unknown driver variable assigned on the command line: a=b.c++
nvc++-Warning-No files to process
instead of the expected:
❯ nvc++ a.c++
Catastrophic error: cannot open source file "a.c++"
1 catastrophic error detected in the compilation of "a.c++".
Compilation terminated.
Is there a way to escape these = in the path? Or allow them on a global scope?
Thanks,
Matthias
Hi Matthias,
We use “=” to pass variables to the compiler driver. For example:
nvc++ CUDA_HOME=/path/to/cuda a.cpp
Hence when this is included in a file name, we interrupted it as a driver option.
In 23.3, we’ll be updating the warning message to make this more clear, but effectively means that you can’t use “=” in filenames.
How big of an issue is this? What is the Spack feature that this is being used for?
-Mat
Hi Mat,
Thank you for the fast clarification. I would have hoped that there would be a whitelist in place on what options can be passed through, or that there would be a possibility to escape the =.
The paths with the = in them are generated with the Spack’s installation path default scheme of /{installation_prefix}/{name}-{version}-{dependency_hash}/, where the version part looks like git.<ref>=develop (associated version in the Spack docs).
I will have a look to see if we can work around this from our end, and drop the version part including the = in the CI setup we use. This would then be only a minor inconvenience.
Thanks,
Matthias