nvhpc building block with C++20 library support about hpc-container-maker HOT 9 CLOSED

I agree, a more elegant solution would be good. A sketch of a solution might be:

gnu10 = gnu(version='10')
Stage0 += gnu10
Stage0 += nvhpc(..., toolchain=gnu10.toolchain)

If toolchain is set, then after the nvhpc installation, it would call makelocalrc -gcc <toolchain.cc> .... I will leave this issue open as an RFE to provide such a solution.

I think there is a bug in how the version is computed when using the url argument. If you look at the environment variables in the output, you'll see they use 22.2 rather than 22.3. A more robust way to do that would be to use tarball=True rather than specifying the url directly. Alternatively, to work around the bug, set both url and version='22.3'.

from hpc-container-maker.

Stage0 += baseimage(image='ubuntu:20.04')
Stage0 += gnu(version='10')
Stage0 += nvhpc(eula=True, cuda_multi=False, url='https://developer.download.nvidia.com/hpc-sdk/22.3/nvhpc_2022_223_Linux_x86_64_cuda_11.6.tar.gz', ospackages=['bc', 'debianutils', 'libatomic1', 'libnuma1', 'openssh-client', 'wget'])

seems to do the trick in terms of not failing on encountering ranges, but there seems to be an issue with nvc++ not being on the path and e.g. thrust not being found...

from hpc-container-maker.

The GNU compiler details are cached when the NVIDIA compilers are installed.

Try:

Stage0 += baseimage(image='nvcr.io/nvidia/nvhpc:22.3-devel-cuda11.6-ubuntu20.04')
Stage0 += gnu(version='10')
Stage0 += shell(commands=['makelocalrc /opt/nvidia/hpc_sdk/Linux_x86_64/22.3/compilers -x -q'])

This will regenerate the localrc using GNU 10. Diff /opt/nvidia/hpc_sdk/Linux_x86_64/22.3/compilers/bin/localrc and /opt/nvidia/hpc_sdk/Linux_x86_64/22.3/compilers/bin/local.bak.

from hpc-container-maker.

@samcmill Yes, this works, thank you! It might still be a good idea to think about a more general/elegant solution when nvhpc wants to support C++23 features in the near future (via the same mechanism? So even newer gcc versions?).

Is the behavior from my last comment expected behavior? It seems like it should also produce the same result as using the building block with the Debian package.

from hpc-container-maker.

I have now found out that gcc 10 is not enough for full C++20 support, as __cplusplus is too low. nvc++ uses this macro to determine how it evaluates iterators to be random access iterators. With the C++17 rules that it will follow wih gcc 10, a transform view does not provide random access iterators, but with C++20 rules it does (new concept). So to use a transform view (and probably others as well) in a parallel algorithm, one needs gcc 11. I tried installing it from source using the building block

Stage0 += gnu(version='11.2.0', source=True)

but got

checking LIBRARY_PATH variable... contains current directory
configure: error: 
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.

Should I file a new issue? Or is this just an oversight on my side (e.g. singularity build flags, I use only --fakeroot)?

from hpc-container-maker.

I haven't looked into the issue building the GNU compilers from source, but here's a simple alternative if you can use Ubuntu 22.04:

Stage0 += baseimage(image='ubuntu:22.04')

Stage0 += gnu()

Stage0 += nvhpc(cuda_multi=False, eula=True)

The default gcc package version in 22.04 is 11.2.0, so this sidesteps all the issues.

from hpc-container-maker.

I'm so used to 20.04 due to all the NGC packages being 20.04 or older, but you are right. There is no good reason to stay with 20.04. Thanks!

from hpc-container-maker.

FWIW, I'm unable to reproduce the LIBRARY_PATH issue in either Docker or Singularity. Singularity has a bad habit of leaking the host environment into the container build, so it may be something specific to your environment?

I expect there to be an Ubuntu 22.04 version of the NGC nvhpc container for the next nvhpc release.

from hpc-container-maker.

That is possible. I already started to use singularity exec -e, but for building -e seems to do something different (encryption) and I didn't find another flag. So I thought that a clean env would be the default, but i may be wrong.

That is good news. Compiling gcc from source for a container build is not something I will miss, even when it works.

from hpc-container-maker.