Closed joequant closed 2 months ago
Hi Joseph,
Yes, gdb is part of the stack, but not only through devtools, but also as a dependency of gaudi ( it's actually an optional dependency so that could be changed. There shouldn't be anything that is requiring an old version of gdb, likely spack just tries to minimize additional dependencies. So I think we should just add a conflict for gcc@8 %gcc@14
, that should let you install a newer version.
let me try to figure out why its pulling in such an old version of gdb
found the problem. gaudi pulls in gdb but gdb includes +python if the version is more than 8.2. So gaudi tries to compile the version of gdb that does not include +python which is 8.1
Include a conflicts in gdb seems to fix everything
Also I am getting some build errors in spack packages because of the new gcc14 error in things like incompatible pointers.
also my changes are in dev/fixes in https://github.com/joequant/spack and https://github.com/joequant/key4hep-stack
I have a script in key4hep-container that applies my patches to the main git and then builds the tree.
Running into compile errors with DD4Hep not picking up a root package
Closing this issue. I've managed to get a build for gcc14 in joequant/key4hep-container and I've added pull requests for the key4hep components.
Build issues for GCC 14 key4hep.
The immediate issue that I run into is that something in the build is pulling in gdb 8.0 which is not available for GCC 14. Another issue is that I am getting issues building py-onnx and py-onnxruntime because of issues pulling in protobuf.
Could the issue be that I am trying to build devtools?