Open ashterenli opened 1 year ago
Can you also share the output of configure? I only tested on x86_64. It'd also be very useful to know what flang -v
and mpif90 -v
emit on Graviton.
The problem with -soname is that the linker flags aren't being decorated with -Wl, properly. For this to happen:
1) Your platform has to be detected as some flavor of Linux so we invoke the appropriate script in config/. All the Linux configs just invoke the linux-gnulibc1 script. This should happen according your config.log, where $host_os is 'linux-gnu' and $host_cpu is 'aarch64'. We don't have any cpu-specific Linux configs, but you should invoke config/linux-gnu when configure runs.
2) Your Fortran compiler has to be detected properly when we run through the Fortran flags files in config. We try each of them and only process the one where we get a compiler version string match. This will set $FC_BASENAME, which we test for at the end of configure to see if we need to hack up the linker options (we only have to do this for flang and the NAG Fortran compiler). If we aren't properly detecting the compiler based on $FC --version
or whatnot, $FC_BASENAME won't be set and we'll skip the linker flag hack. That linker flag hack just runs awk over the generated libtool script in the build root. It'll have sections for C, C++, and Fortran. You can manually copy the -Wl, over (as it'll be in the C section) to see if that's the only thing that is going wrong. It's also possible that we're incorrectly detecting your Fortran compiler and setting $FC_BASENAME to the wrong thing.
Code freeze for 1.14.3 is Monday, btw. If you want this fixed for that version, you'll have to get me this info over the weekend.
btw, I also see that you specified -fopenmp as an option. We don't use OpenMP in HDF5. In fact, we build with -nomp w/ flang.
@derobins Thank you for a quick analysis.
I'll provide what you requested shortly.
The output of configure
is config.log
- I attached it in the initial comment.
$ flang -v
Arm C/C++/Fortran Compiler version 23.10 (build number 32) (based on LLVM 17.0.0)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/arm-linux-compiler-23.10_AmazonLinux-2/bin
Found candidate GCC installation: /bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/gcc-12.2.0_AmazonLinux-2/lib/gcc/aarch64-linux-gnu/12.2.0
Selected GCC installation: /bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/gcc-12.2.0_AmazonLinux-2/lib/gcc/aarch64-linux-gnu/12.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found CUDA installation: /usr/local/cuda, version 11.7
$ mpif90 -v
Arm C/C++/Fortran Compiler version 23.10 (build number 32) (based on LLVM 17.0.0)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/arm-linux-compiler-23.10_AmazonLinux-2/bin
Found candidate GCC installation: /bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/gcc-12.2.0_AmazonLinux-2/lib/gcc/aarch64-linux-gnu/12.2.0
Selected GCC installation: /bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/gcc-12.2.0_AmazonLinux-2/lib/gcc/aarch64-linux-gnu/12.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found CUDA installation: /usr/local/cuda, version 11.7
[ec2-user@c7g-2-maz-dy-c7g2-1 ape]$
BTW, here's a patch to fix libtool:
This is supposed to be fixed in https://github.com/HDFGroup/hdf5/pull/3674 but I still see it with the latests develop commit: https://github.com/HDFGroup/hdf5/commit/b916ce2419da45f7a51503e3bf2774e71f7db815
Using aws graviton3 - arm:
-mcpu=neoverse-512tvb -march=armv8.4-a+sve
arm compiler 23.10, and openmpi 4.1.6.I attach
config.log
if this helps. config.log