Fix spack images#35
Conversation
| ARG REGISTRY=ghcr.io/pdidev/test_env | ||
|
|
||
| FROM ghcr.io/pdidev/test_env/base:${IMAGE_TAG} | ||
| FROM ${REGISTRY}/base:${IMAGE_TAG} |
There was a problem hiding this comment.
Do we want to keep this registry? It is relevant for example if we want to test in our fork.
@jbigot @benoitmartin88
| @@ -1 +1 @@ | |||
| llvm+llvm_dylib+link_llvm_dylib~lldb | |||
| llvm+llvm_dylib+link_llvm_dylib~lldb+gold | |||
There was a problem hiding this comment.
gold linker seems to be deprecated (search for a maintainer)
https://packages.spack.io/package.html?name=llvm#:~:text=false%29%20Add%20support%20for%20LTO%20with%20the%20gold%20linker%20plugin%20%28deprecated
There was a problem hiding this comment.
Just to be clear, is it Gold itself that is deprecated, and not its Spack.
Why is this variant needed here ?
There was a problem hiding this comment.
See failure
Doxygen is built with link time optimization (LTO). Building with link time optimization requires cooperation from the system linker. LTO support on Linux systems is available via the gold linker which has a plugin interface. The LLVM gold plugin is an implementation of this interface.
To avoid using the deprecated approach, it seems that the alternative is to use LLVM native linker (LLD). I am currently testing this approach but I still did not manage to make it work.
|
|
||
|
|
||
| COPY ${COMPILER}.lst compilerpkg.lst | ||
| RUN <<EORUN |
There was a problem hiding this comment.
May quote all EORUN of this PR (also relevant for files not modified by this PR)
| RUN <<EORUN | |
| RUN <<'EORUN' |
There was a problem hiding this comment.
if we use quote, the ${expression}, inside the here document, will not be evaluated.
There was a problem hiding this comment.
With the quotes, Docker does not expand the expressions, but the shell still does
This is why we also have COPY <<'EOCOPY' spack.yaml in this file
From what i understand, we can quote all EORUN/EOCOPY here (as it would be more practical to identify a potential issue in the future with a unified syntax)
…to COMPILER_SPECIFIC_VARIANTS
3 participants
Fixes issue #34