When using hip and friends as externals, the install will in many cases not be set up to use a specific compiler/GCC standard library but will simply pick up the first one it finds from some system install directory, and this will often not be the same GCC as the one specified as the compiler in a spec.

One problematic case that we bumped into with this is if the system GCC is version 13 and a spack spec uses %gcc@12, where GCC 12 is installed in some non-standard location. However, when a package depends on HIP compilation through hipcc/HIP's clang would pick up GCC 13 (or libstdc++ from GCC 13). The rest of the code would be compiled with the correct GCC 12. Since GCC is not compatible in this direction (forward?), i.e. an application built with a newer version of libstdc++ can't be linked later to an older version of libstdc++. For searchability, the error you'd get in this case while linking is

undefined reference to `std::ios_base_library_init()'

This PR attempts to fix this when hip is external and the compiler is %gcc. It will set in dependent environments:

• HIPCC_COMPILE_FLAGS_APPEND to include --gcc-toolchain pointing to the prefix of GCC. This is picked up by hipcc. This will be used e.g. by CMake packages that set CMAKE_CXX_COMPILER to hipcc.
• HIPFLAGS to include the same as above. This is picked up by CMake for the initial value of CMAKE_HIP_FLAGS. When using HIP as a CMake language (at least in newer versions of CMake) HIP's clang++ will be used for compilation, so HIPCC_COMPILE_FLAGS_APPEND wouldn't work here.

As far as I understand if someone sets CMAKE_HIP_FLAGS explicitly, this will override HIPFLAGS. This is not perfect, but as far as I could tell no package is setting CMAKE_HIP_FLAGS at the moment.

I don't know if any of this will help non-CMake packages, but it should not hurt them at least.

llvm-amdgpu when built through spack will set GCC_INSTALL_PREFIX during configuration so the above is only used when hip is external. I suppose the workaround could also be set in llvm-amdgpu but I feel like hip is the semantically right place for these since that is what packages will usually depend on. The environment variables that are being set are also HIP flags, not llvm-amdgpu flags, and I don't think they'd have any effect if one depends only on llvm-amdgpu and uses clang++ directly from there. I don't know if this is a naive assumption?