I installed nvhpc_2024_241_Linux_x86_64_cuda_12.3 following the instruction and the compiler works. However, my system compiler is g+±12, while all development is done in micromamba (conda) environments, where I’m using g+±13. One of the consequences is, that std::views::cartesian_productis not available, as in g+±12, however g+±13 knows it. For me this is an indication, that nvc++ is using the system compiler, not the one from the micromamba environment. Besides not being able to test the examples from the NVC++ videos, this will cause all kinds of linking problems for real work.
Is there a possibility for installing nvc++ in a way, that it uses the std++ standard library shipped with the one in the micromamba environment?
Thanks in advance,
best regards,
Peter
Hi Peter,
In order to be interoperable with g++, nvc++ uses the g++ STL.
By default, it will use the STL that ships with the system but if you use the flag “–gcc-toolchain=/path/to/gnu/dir”, it will use the STL from another installation.
Alternatively, you can create a new compiler config file, “localrc”, using g++13 by running the “makelocalrc” utility.
makelocalrc -d . -x -gcc=/path/to/bin/gcc -gpp=/path/to/bin/g++ -g77=/path/to/bin/gfotran
This will create a “localrc” file in the current directory which you can move and/or rename. Then set the environment variable “NVLOCALRC” to the full path to this file to use it.
Hope this helps,
Mat
Dear Mat,
thanks for your fast response.
Sadly I have not managed to get it running, which seems to
be related to the way conda installs g++, and I’m not sure which path
I should enter.
The g++ executable is installed at ${CONDA_PREFIX}/bin/g++.
makelocalrx complains that it doesn’t find the according directory.
The gcc libraries are at ${CONDA_PREFIX}/lib/gcc/x86_64-conda-linux-gnu/13.2.0, e.g.
ls ${CONDA_PREFIX}/lib/gcc/x86_64-conda-linux-gnu/13.2.0/ :
builtin.specs crtbeginS.o crtend.o crtfastmath.o crtprec64.o include install-tools libgcc_eh.a libiberty.a libstdc++exp.a libstdc++.so plugin
crtbegin.o crtbeginT.o crtendS.o crtprec32.o crtprec80.o include-fixed libgcc.a libgcov.a libstdc++.a libstdc++fs.a libsupc++.a specs
The c++ header seem to be located in ${CONDA_PREFIX}/x86_64-conda-linux-gnu/include/c++/13.2.0 :
NV: ls ${CONDA_PREFIX}/x86_64-conda-linux-gnu/include/c++/13.2.0
algorithm ciso646 cstdio filesystem math.h set tgmath.h
any climits cstdlib format memory shared_mutex thread
array clocale cstring forward_list memory_resource source_location tr1
atomic cmath ctgmath fstream mutex span tr2
backward codecvt ctime functional new spanstream tuple
barrier compare cuchar future numbers sstream typeindex
bit complex cwchar initializer_list numeric stack typeinfo
bits complex.h cwctype iomanip optional stacktrace type_traits
bitset concepts cxxabi.h ios ostream stdatomic.h unordered_map
cassert condition_variable debug iosfwd parallel stdexcept unordered_set
ccomplex coroutine decimal iostream pstl stdfloat utility
cctype csetjmp deque istream queue stdlib.h valarray
cerrno csignal exception iterator random stop_token variant
cfenv cstdalign execution latch ranges streambuf vector
cfloat cstdarg expected limits ratio string version
charconv cstdbool experimental list regex string_view x86_64-conda-linux-gnu
chrono cstddef ext locale scoped_allocator syncstream
cinttypes cstdint fenv.h map semaphore system_error
I tried various combinations of paths for makelocalrc or nvc++ –gcc-toolchain .. without success.
Any idea on which path I should provide.
Thanks in advance,
best regards,
Peter
It’s the base directory of the GNU install, so in this case it should be “–gcc-toolchain=${CONDA_PREFIX}”
For the localrc method, it would be:
makelocalrc -d . -x -gcc=${CONDA_PREFIX}/bin/gcc -gpp=${CONDA_PREFIX}/bin/g++ -g77=${CONDA_PREFIX}/bin/gfortran
Then set the environment variable NVLOCALRC=/path/to/my/localrc
Mmmh, it still doesn’t work, I get the following messages:
nvc++-Warning-unknown driver variable assigned on the command line: –gcc-toolchain=..../micromamba/envs/...
/usr/bin/ld: warning: /tmp/pgcudafatk3GcE4ZD2P7G.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
where I replaced personal data by ....
Yet It produces a running binary for an example with C++17 only.
However, using cartesian_products, does not work, although the same code compiles in g++13.2.
To be sure I have uninstalled the system g+±12.
BTW, nvc++ ... -ltbbparallelizes better than nvc++ … --stdpar=multicorefor a simplistic std::sort example.-stdpar=gpu` is however the fastest option. That’s really nice.
The makelocalrcapproach also doesn’t work. It says that the according directories are not found.
However, the provided binaries do exist. I’m really puzzled.
I tried a simple makelocalrc -x $HOME/NVidia/hpc_sdk/Linux_x86_64/24.1/compilers/bin
and now things changed.
Instead of the previous error
"views.C", line 32: error: namespace "std::ranges::views" has no member "cartesian_product"
I now get
class chunk_view<_Vp>::_Iterator
^
1 error detected in the compilation of "views.C".
(where I replaced the directory prefix with $HOME)
Not sure whether that is a nvc++ problem, or my incomplete installation (without the proper -gpp flags).
The code I’m testing is the example from std::ranges::views::cartesian_product, std::ranges::cartesian_product_view - cppreference.com .
My apologies Peter, I had a typo above in that the flag is “–gcc-toolchain” (i.e. two dashes). That’s why you have that weird error.
For makelocalrc, yes you’ll want the “-gpp” flag set since the script will query g++ for the location of the header files, which is then stored in the localrc.
Actually it also doesn’t work with “–”. I still get a directory not found.
Ok though unfortunately I don’t know the conda environment so not sure why the base directory could not be found by the driver.
I tried to change the variables directly in the m̀akelocalrc`script:
gcc="${CONDA_PREFIX}/bin/gcc"
gpp="${CONDA_PREFIX}/bin/g++"
gfortran="${CONDA_PREFIX}/bin/gfortran"
Then the script doesn’t complain. However the compiler has issues with linking:
/usr/bin/ld: cannot find -latomic
It’s now late here. so I’ll continue tomorrow. Thanks for your help.
I added -L ${CONDA_PREFIX}/x86_64-conda-linux-gnu/lib to the linking, then it complains that
/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.31’
So, it compiles, but looks for the wrong libstdc++. Thast’s one of the weird thing within conda.
Update:
To fix this problem I set export LD_LIBRARY_PATH=${CONDA_PREFIX}/x86_64-conda-linux-gnu/lib
Finally it compiles my C++17 examples, and it runs fine, while the system g+±12 is de-installed.
However, the cartesian_product example mentioned before does not compile, while it compiles with g++. I’m afraid at this point I have to give up, which is a pity as I was excited by the C++ Standard Parallelism - Bryce Adelstein Lelbach - GTC 2023 - S51755presentation and wanted to test the code at 46:00.
I just gave the example a try and it compiled for me. I just needed to add the “-std=c++23” flag to enable the feature level.
% nvc++ cart.cpp --std=c++23 --gcc-toolchain=/home/sw/thirdparty/gcc/gcc-13.2.0/Linux_x86_64/
% a.out
(A 1 α) (A 1 β) (A 1 γ) (A 1 δ)
(A 2 α) (A 2 β) (A 2 γ) (A 2 δ)
(A 3 α) (A 3 β) (A 3 γ) (A 3 δ)
(B 1 α) (B 1 β) (B 1 γ) (B 1 δ)
(B 2 α) (B 2 β) (B 2 γ) (B 2 δ)
(B 3 α) (B 3 β) (B 3 γ) (B 3 δ)
Thanks a lot, I got it running now. Looks like the conda installation of g+±13 is a little bit messed up.
While your example did not immediately work, it was the hint to get it running. In essence I only need the --gcc-toolchain option, in addition I have to explicitly include the path for the libs. I assume nvc++ is using the system ldd to find the libraries, and conda does not provide its own ldd with the corresponding ld.config. Also exporting the LD_LIBRARY_PATH it finally works:
NV: export LD_LIBRARY_PATH=${CONDA_PREFIX}/x86_64-conda-linux-gnu/lib
NV: nvc++ views.C --std=c++23 --gcc-toolchain=${CONDA_PREFIX}/bin/gcc -L ${CONDA_PREFIX}/x86_64-conda-linux-gnu/lib -o views && ./views
(A 1 α) (A 1 β) (A 1 γ) (A 1 δ)
(A 2 α) (A 2 β) (A 2 γ) (A 2 δ)
(A 3 α) (A 3 β) (A 3 γ) (A 3 δ)
(B 1 α) (B 1 β) (B 1 γ) (B 1 δ)
(B 2 α) (B 2 β) (B 2 γ) (B 2 δ)
(B 3 α) (B 3 β) (B 3 γ) (B 3 δ)
Thanks a lot, I hope this enables me to look at the more interesting examples.
At least it looks promising, and is important, as we all our CICD pipelines run in micromamba environments.
All the best,
Peter
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.