Closed trz42 closed 1 year ago
The default gcc version has been increased to 10.4.0 (see prefix_default_gcc: 10.4.0). (Requirement in upstream bootstrap-prefix.sh script.)
You know you don't need to stick to that after installing, right? You can and should update to a newer version of GCC if you want. Only the bootstrap process is a bit finicky, but once you bootstrap, you are usually free from the constraints. You can also install multiple versions of GCC (i.e. GCC 12 for CPU, GCC 11 for CUDA), which you can use later as gcc-$version
on the command line even if they are not the default.
The default gcc version has been increased to 10.4.0 (see prefix_default_gcc: 10.4.0). (Requirement in upstream bootstrap-prefix.sh script.)
You know you don't need to stick to that after installing, right? You can and should update to a newer version of GCC if you want. Only the bootstrap process is a bit finicky, but once you bootstrap, you are usually free from the constraints. You can also install multiple versions of GCC (i.e. GCC 12 for CPU, GCC 11 for CUDA), which you can use later as
gcc-$version
on the command line even if they are not the default.
Good to know. I think for EESSI we only need one version that is then used to build up tools chains (incl compilers) in the software layer. In the past we ran into issues with too recent versions of GCC in that step. Hence, we'd rather like to restrict ourselves to the oldest version of GCC in the compat layer. Might change in the future when we move to more recent tool chains in the software layer.
I see. I suggest to try using the toolchain from the compat layer to build the software layer, to avoid having to add ld wrappers, etc, since the toolchain is already configured to work well with the non-standard glibc and linker. It will also let you control binutils with eselect-binutils
, etc. I read the diffs and the reason to use <GCC-11 is because GCC-11 needs C++11 support to build, which may not be available on old OSs like CentOS 7, etc. Other than that, you should be able to remove the restriction, as I believe other compilation problems have been solved.
I'd rather reconfigure the ansible-lint check to ignore the Jinja template issue. The script has run fine a dozen of times. The "ERROR" only states that templates should be at the end, so it doesn't matter. Also curious why we need to fix this here. Maybe it is better to do a code quality hackathon than imposing unrelated code improvements to PRs.
Probably interesting finds on building the compat layer:
direnv
easily, so removed it from the overlay sets. nss
and stop
built without any issues. rpm
wasn't added as it didn't seem needed for GPU support.x86_64
.aarch64
I ran into issues that community.general.portage
is not a known ansible
module action. So, will have to revert that until a proper fix is found. Previously, only portage
was used but ansible-lint
complained something like
fqcn[action]: Use FQCN for module actions, such `<namespace>.<collection>.portage`. (warning)
[1281](https://github.com/EESSI/compatibility-layer/actions/runs/3385280194/jobs/5623244261#step:4:1282)
ansible/playbooks/roles/compatibility_layer/tasks/add_overlay.yml:22 Action `portage` is not FQCN.
[1282](https://github.com/EESSI/compatibility-layer/actions/runs/3385280194/jobs/5623244261#step:4:1283)
x86_64
and aarch64
different wrt the ansible
installation?This PR has become obsolete with new developments in early 2023.
This includes a number of updates to the current version (2021.12):
File
bootscript-prefix.sh
:bootstrap-prefix.sh
has been sync'ed with updates to the upstream version (https://github.com/gentoo/prefix.git) until a recent update on Nov 2 2022. The script here still includes a few changes we may want to revisit i.e. if they are necessary or if they can be removed to allow us to just use the upstream script.diff gentoo-prefix/scripts/bootstrap-prefix.sh EESSI-compatibility-layer/bootstrap-prefix.sh
):File
ansible/playbooks/roles/compatibility_layer/defaults/main.yml
:2022.11
. (eessi_version: "2022.11"
)custom_overlays.url: https://github.com/trz42/gentoo-overlay.git
)gentoo_git_commit: cec3214ef5d5661e28c9d2c5b5750b27c27c5435
) being used is updated to a more recent version (from Nov 3 2022). A bit information about history of used commits was added. Can be removed if deemed unnecessary.gcc
version has been increased to10.4.0
(seeprefix_default_gcc: 10.4.0
). (Requirement in upstreambootstrap-prefix.sh
script.)gcc
being used had to be restricted to anything before10.4.1
because some10.4.1_p*
ebuilds were added to https://github.com/gentoo/gentoo/sys-devel/gcc recently. While those installed fine during the bootstrap stages 2/3, it was not immediately clear how to set them as default withgcc-config
. Simply setting them viaprefix_default_gcc
(see item on default gcc) didn't work. (see line>=sys-devel/gcc-10.4.1
forprefix_mask_packages:
)prefix_singularity_command
were changed to unsetLD_LIBRARY_PATH
(thebootstrap-prefix.sh
in2021.12
had a slight spelling typo in the check ifLD_LIBRARY_PATH
is set, hence went on even if it was set). The updatedbootstrap-prefix.sh
checks for the correct variable.File
ansible/playbooks/roles/compatibility_layer/tasks/install_packages.yml
:root
permissions. (Could be an issue with testing setup. Might be good to verify if it is needed in other environments.)