# (Un) Successful compile of stdlib with Nvidia Fortran **URL:** \ **Category:** Compilers\ **Created:** [May 20, 2025, 9:11pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755 "2025-05-20T21:11:01Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![BB\_UK](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@BB\_UK](https://fortran-lang.discourse.group/u/BB_UK)\ **Post date:** [May 20, 2025, 9:11pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/1 "2025-05-20T21:11:01Z")
Hello all, Newly registered and wanted to share with you my experience in building stdlib: OS: Ubuntu Gnome desktop 22.04.5 LTS CPU: 2x AMD Epyc 7343. 512GB ram. nvfortran: 24.11-0 (supports my 1660Super gfx card - Turing arch) Nvidia env setup via modules. Python3.10 env for fypp setup with venv. CMAKE\_INSTALL\_PREFIX=/home/bob/local/Fortran\_stdlib/stdlib After cloning the stdlib Git repo into stdlib\_src I ran from that directory: `cmake --fresh -B build -DCMAKE_INSTALL_PREFIX=/home/bob/local/Fortran_stdlib/stdlib` and experienced no problems. Followed by: `cmake --build build` with no incident. …and: `cmake --build build --install test` which ran through all tests without an error, in just over 32s. I hope this provides some helpful feedback. Bob. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 20, 2025, 10:54pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/2 "2025-05-20T22:54:06Z")
Welcome to the community @BB_UK I’m surprised to say the least. stdlib has several 2008 features that nvfortran does not yet support AFAIK. I have nvfortran 24.11 on one machine and got the 25.5 version in another… with neither have I been able to build stdlib as there are several modules which will fail due to those features. Sorry to play the skeptic but, are you sure that when you compiled it was not the default gnu compilers that took over? Even if you activate the nvidia hpc\_sdk module, most probably you have gnu11 by default, and if you did not specify the compilers with `-DCMAKE_Fortran_COMPILER=nvfortran -DCMAKE_C_COMPILER=nvcc -DCMAKE_CXX_COMPILER=nvcc` it is likely that you actually compiled with gfortran/gcc instead of nvfortran/nvcc. ---
**Author:** ![BB\_UK](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@BB\_UK](https://fortran-lang.discourse.group/u/BB_UK)\ **Post date:** [May 21, 2025, 7:16pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/3 "2025-05-21T19:16:48Z")
Let me retry that compile. ---
**Author:** ![BB\_UK](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@BB\_UK](https://fortran-lang.discourse.group/u/BB_UK)\ **Post date:** [May 21, 2025, 7:33pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/4 "2025-05-21T19:33:33Z")
First cmake run: ```auto cmake -B build -DCMAKE_Fortran_COMPILER=nvfortran -DCMAKE_C_COMPILER=nvcc -DCMAKE_CXX_COMPILER=nvcc -DCMAKE_INSTALL_PREFIX=/home/bob/local/Fortran_stdlib/stdlib --fresh -- The Fortran compiler identification is NVHPC 24.11.0 -- The C compiler identification is GNU 11.4.0 -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Check for working Fortran compiler: /opt/nvidia/hpc_sdk/Linux_x86_64/24.11/compilers/bin/nvfortran - skipped -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /opt/nvidia/hpc_sdk/Linux_x86_64/24.11/compilers/bin/nvcc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Performing Test WITH_CBOOL -- Performing Test WITH_CBOOL - Success -- Performing Test WITH_QP -- Performing Test WITH_QP - Failed -- Performing Test WITH_XDP -- Performing Test WITH_XDP - Failed -- Performing Test f18errorstop -- Performing Test f18errorstop - Success -- Performing Test f03rank -- Performing Test f03rank - Failed -- Performing Test f03real128 -- Performing Test f03real128 - Failed -- Searching for external BLAS/LAPACK -- Looking for Fortran sgemm -- Looking for Fortran sgemm - not found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE -- Looking for Fortran sgemm -- Looking for Fortran sgemm - found -- Found BLAS: /usr/lib/x86_64-linux-gnu/libopenblas.so -- Looking for Fortran cheev -- Looking for Fortran cheev - found -- Found LAPACK: /usr/lib/x86_64-linux-gnu/libopenblas.so;-lm;-ldl -- Found external BLAS: /usr/lib/x86_64-linux-gnu/libopenblas.so -- Found external LAPACK: /usr/lib/x86_64-linux-gnu/libopenblas.so;-lm;-ldl -- Using standard 32-bit integer interface -- test-drive: Find installed package -- The CXX compiler identification is GNU 11.4.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /opt/nvidia/hpc_sdk/Linux_x86_64/24.11/compilers/bin/nvcc - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/bob/local/Fortran_stdlib/stdlib_src/build ``` 2nd run: ```auto [15%] Building Fortran object src/CMakeFiles/fortran_stdlib.dir/stdlib_error.f90.o NVFORTRAN-S-0034-Syntax error at or near identifier rank (/home/bob/local/Fortran_stdlib/stdlib_src/build/src/stdlib_error.f90: 382) NVFORTRAN-S-0034-Syntax error at or near end of line (/home/bob/local/Fortran_stdlib/stdlib_src/build/src/stdlib_error.f90: 383) NVFORTRAN-S-0034-Syntax error at or near end of line (/home/bob/local/Fortran_stdlib/stdlib_src/build/src/stdlib_error.f90: 385) NVFORTRAN-S-0034-Syntax error at or near identifier default (/home/bob/local/Fortran_stdlib/stdlib_src/build/src/stdlib_error.f90: 387) 0 inform, 0 warnings, 4 severes, 0 fatal for appendr gmake[2]: *** [src/CMakeFiles/fortran_stdlib.dir/build.make:996: src/CMakeFiles/fortran_stdlib.dir/stdlib_error.f90.o] Error 2 gmake[1]: *** [CMakeFiles/Makefile2:2455: src/CMakeFiles/fortran_stdlib.dir/all] Error 2 gmake: *** [Makefile:146: all] Error 2 ``` Ah ha ! Now don’t I feel a bit silly ! 😃 ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 21, 2025, 7:42pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/5 "2025-05-21T19:42:34Z")
Happens, let me extend a virtual hug of sympathy! My understanding is that nvfortran is under minimal maintenance as Nvidia is investing heavily on flang [Welcome to Flang’s documentation — The Flang Compiler](https://flang.llvm.org/docs/), which I imagine will replace it once it reaches production readiness. If you want to do GPU programming and also use (help improve maybe?) stdlib, you can consider installing the GNU offloading extension instead. You might not get the top notch performance from the vendors compilers but at least get the gists of the craft. If you haven’t read it yet, I’m suspecting this whole thread might interest you [GPU offloading in Fortran - #34 by hkvzjal](https://fortran-lang.discourse.group/t/gpu-offloading-in-fortran/9120/34) ---
**Author:** ![BB\_UK](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@BB\_UK](https://fortran-lang.discourse.group/u/BB_UK)\ **Post date:** [May 21, 2025, 8:58pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/6 "2025-05-21T20:58:50Z")
Thanks for the link, that was an interesting read. So my options are, basically: 1. Cuda Fortran compiled with nvfortran allowing me to write cuda kernels, but does not support features in the stdlib. (There was something about NVHPC v24.11 that was the last release to support my hardware - so I haven’t even tried any later releases.) 2. gfortran with GPU extension to offload loops to the GPU & support for the stdlib previously mentioned, but no ability to code cuda kernels. For now, I believe both options are fine. Coding isn’t my day job; PCB layout and database management is. Cheers, Bob. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [May 24, 2025, 6:46am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/7 "2025-05-24T06:46:59Z")
I guess you can mix gfortran (to have the recent additions to the standard) and nvfortran (to write GPU kernels and wrappers to them). Just, you are then restricted to pure F77 style interfaces between them. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 24, 2025, 7:22am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/8 "2025-05-24T07:22:04Z")
You could in principle also mix intel and nvidia compilers: > > **[Accelerating Fortran codes: A method for integrating Coarray Fortran with...](https://www.sciencedirect.com/science/article/pii/S0743731524001412)** > > Fortran's prominence in scientific computing requires strategies to ensure both that legacy codes are efficient on high-performance computing systems,… ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [May 24, 2025, 10:24am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/9 "2025-05-24T10:24:11Z")
Yes, I remember that article. But honestly I find the solution overly complicated. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 24, 2025, 10:26am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/10 "2025-05-24T10:26:31Z")
Definitely! That’s why I haven’t bothered trying myself, but it was an interesting read though. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [May 24, 2025, 11:10am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/11 "2025-05-24T11:10:30Z")
What is missing in the standard is in my opinion is a standardized ABI that would allow modern Fortran interfaces between different compilers. In practice it would be standardized .mod files. It could be optional, enabled with a `bind(Fortran)` specifier. ---
**Author:** ![AniruddhaDas](https://avatars.discourse-cdn.com/v4/letter/a/8491ac/32.png) [@AniruddhaDas](https://fortran-lang.discourse.group/u/AniruddhaDas)\ **Post date:** [May 24, 2025, 11:32am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/12 "2025-05-24T11:32:00Z")
There is a paper called `F202Y Global binding name for non C-interoperable` numbered [23-201](https://j3-fortran.org/doc/year/23/23-201.txt). But the paper states this > This is _not_ intended to provide a mechanism to call a procedure compiled with one compiler via a program compiled with a different compiler. 🙂 ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [May 24, 2025, 11:43am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/13 "2025-05-24T11:43:17Z")
The `bind(c)` approach works to use multiple Fortran compilers in the same project, except descriptor arrays, which do have an API, but not an ABI, and while one could write adaptors per compiler, as suggested here: [blog/Dealing\_with\_imperfect\_Fortran\_compilers\_2.md at main · jeffhammond/blog · GitHub](https://github.com/jeffhammond/blog/blob/main/Dealing_with_imperfect_Fortran_compilers_2.md#duct-tape-part-1), it would be better to figure out an ABI for this, like for the rest of the `bind(c)` features. One can imagine adding more Fortran features into this `bind(c)` subset. There is some tiny overhead at the API boundary, as the Fortran compiler must convert internal representation to the ABI-stable C interface, but this is made explicit by the programmer using `bind(c)` in the function declaration. The data is not copied but the descriptor might. That seems acceptable. The `bind(Fortran)` approach might work in a similar way. Possibly it might not even be needed if `bind(c)` is powerful enough. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [May 24, 2025, 2:00pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/14 "2025-05-24T14:00:47Z")
> [@PierU](#): > > In practice it would be standardized .mod files. Why there has been no effort to come up with a standardized module format is still a puzzle to me. Personally, I would place a higher priority on adding a standardized module format to the language than about 99% of the things that have been added in F23 and proposed for F2Y. The amount of time wasted building compiler specific versions of Fortran libraries just because the module formats are incompatible alone justifies some effort to standardized formats. I think a standard format could easily exist with native module formats and act as a “bridge” between compilers in the same way the Coordinate based sparse matrix storage formats act as a bridge between other storage formats in some (most) sparse matrix packages. ---
**Author:** ![RJaBi](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/rjabi/32/5161_2.png) [@RJaBi](https://fortran-lang.discourse.group/u/RJaBi)\ **Post date:** [May 24, 2025, 5:29pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/15 "2025-05-24T17:29:44Z")
While nice, I lack confidence that the (commercial) compiler developers would view it as a priority. As we’ve discussed already in this thread, the Nvidia compiler is not usuable for proper Modern Fortran (It also does not support coarray syntax on a single image like gfortran does.) Flang-new will get there (It at least gives not-implemented error messages rather than mysteriously fails to compile), but it is a long way from being fully ready in my view and experience (I spent three days with the AMDflang-new last month). Intel does best in my experience, but is of course not actually useful for Nvidia/AMD GPUs. So if they don’t even have existing (and long-existing) features, why would they implement something to make it easier to not use their compiler? ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [May 24, 2025, 7:01pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/16 "2025-05-24T19:01:59Z")
> [@PierU](#): > > What is missing in the standard is in my opinion is a standardized ABI that would allow modern Fortran interfaces between different compilers. The ABI includes aspects like the processor instruction set and calling conventions. With the multitude of machines on the market, I don’t think this is something the Fortran committee can (or is supposed to) tackle. * * * > [@PierU](#): > > I guess you can mix gfortran (to have the recent additions to the standard) and nvfortran (to write GPU kernels and wrappers to them). Just, you are then restricted to pure F77 style interfaces between them. I think this means you are restricted to the Fortran subset which is part of the System V x86-64 ABI: [x86-64-ABI/fortran.tex · master · x86 psABIs / x86-64 psABI · GitLab](https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/fortran.tex?ref_type=heads) In principle you can pass your suggestions for improvements here: [https://groups.google.com/g/x86-64-abi](https://groups.google.com/g/x86-64-abi) Other architectures also have their own ABIs, for instance - [GitHub - ARM-software/abi-aa: Application Binary Interface for the Arm® Architecture](https://github.com/ARM-software/abi-aa) - [RISC-V ABIs Specification](https://drive.google.com/file/d/1Ja_Tpp_5Me583CGVD-BIZMlgGBnlKU4R/view) and ways to pass them suggestions. The main obstacle I see is that currently all vendors use their own array descriptor. There are are also other obstacles, like e.g. allocatable arrays: ```auto subroutine foo(a) real, allocatable :: a(:) ! ... end subroutine ``` To make allocation and deallocation work, the compilers also need to share the runtime library. So there are many things which have to be discussed, and the reality is the majority of Fortran programmers don’t care _how_ these things are implemented. ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [May 24, 2025, 7:08pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/17 "2025-05-24T19:08:15Z")
> [@rwmsu](#): > > Why there has been no effort to come up with a standardized module format is still a puzzle to me. Personally, I would place a higher priority on adding a standardized module format to the language than about 99% of the things that have been added in F23 and proposed for F2Y. Flang made an interesting decision that the module format is a stripped-down version of the original module. For example if I take [`stdlib_array`](https://raw.githubusercontent.com/fortran-lang/stdlib/refs/heads/master/src/stdlib_array.f90) module as an example, after compilation with flang I get, ```txt $ flang-new -c stdlib_array.f90 $ cat stdlib_array.mod !mod$ v1 sum:ee48f2a609b77219 module stdlib_array private::logicalloc contains pure function trueloc(array,lbound) result(loc) logical(4),intent(in)::array(:) integer(4),intent(in),optional::lbound integer(4)::loc(1_8:int(count(array),kind=8)) end pure function falseloc(array,lbound) result(loc) logical(4),intent(in)::array(:) integer(4),intent(in),optional::lbound integer(4)::loc(1_8:int(count(.NOT.array),kind=8)) end pure subroutine logicalloc(loc,array,truth,lbound) integer(4),intent(out)::loc(:) logical(4),intent(in)::array(:) logical(4),intent(in)::truth integer(4),intent(in),optional::lbound end end ``` The rationale is explained here: [Module Files — The Flang Compiler](https://flang.llvm.org/docs/ModFiles.html) ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [May 24, 2025, 7:37pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/18 "2025-05-24T19:37:04Z")
The hermetic module file option looks interesting. Sorta like what I sometimes do in having a “master” mod file that just contains USE directives for all the modules in program. Of course you have to be very careful to avoid name conflicts between various modules but I do that as a matter of personal coding standards. Once something has a name in one module that name is not repeated in other parts of the code. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [May 26, 2025, 11:20am UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/19 "2025-05-26T11:20:48Z")
> [@ivanpribec](#): > > The ABI includes aspects like the processor instruction set and calling conventions. With the multitude of machines on the market, I don’t think this is something the Fortran committee can (or is supposed to) tackle. Agree, and this would go against the “hardware agnostic” principle that drives the standard. There could be recommendations, though, which would not be part of the standard. And the committee still looks the most appropriate place to issue such recommendations. > [@rwmsu](#): > > Why there has been no effort to come up with a standardized module format is still a puzzle to me. Probably because the module approach can potentially enable hardware dependent optimizations, for instance by specifying that a given argument must be passed in a register rather than on the stack. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [May 26, 2025, 3:52pm UTC](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755/20 "2025-05-26T15:52:18Z")
> [@PierU](#): > > Agree, and this would go against the “hardware agnostic” principle that drives the standard. This is something I’ve wondered about for decades. Historically, fortran programs require the same compiler for the whole program. Certainly now because of modules, optional arguments, assumed shape arguments, and so on, there are many low-level code conventions and low-level data structures that must be shared throughout the code, and if those aren’t standardized somewhere, either by the language standard, or an OS standard, or by a hardware-specific standard, then interoperability among compilers is impossible. There are also i/o library conventions which make it difficult, or impossible, to write routines that can be compiled by one compiler and used by another. Yet, somehow, C compilers seem to do this much better than fortran compilers. Anyone know why? It may not always work, but it is not unusual at all for objects compiled with one C compiler to work seamlessly with other compilers. What is it that makes this difference in the languages? To what extent is this feature shared by C++ compilers, especially with code that uses the higher-level features of the language? [Next page](https://fortran-lang.discourse.group/t/un-successful-compile-of-stdlib-with-nvidia-fortran/9755.md?page=2)