Matt Thompson

@ggouaillardet I grabbed 5.0.1 and did: ``` ml comp/gcc/12.3.0 comp/intel/2023.2.1-ifx mkdir build-intel-2023.2.1-ifx-SLES15 && cd build-intel-2023.2.1-ifx-SLES15 ../configure --disable-wrapper-rpath --disable-wrapper-runpath --with-slurm \ --with-pmix=internal --with-hwloc=internal --with-libevent=internal \ CC=icx CXX=icpx FC=ifx \ --prefix=/discover/swdev/gmao_SIteam/MPI/openmpi/5.0.1-SLES15/intel-2023.2.1-ifx |&...

``` $ mpirun -np 1 ldd ./just_init.exe linux-vdso.so.1 (0x00007ffe50591000) libmpi_usempif08.so.40 => /discover/swdev/gmao_SIteam/MPI/openmpi/5.0.1-SLES15/intel-2023.2.1-ifx/lib/libmpi_usempif08.so.40 (0x000014c7e4850000) libmpi_usempi_ignore_tkr.so.40 => /discover/swdev/gmao_SIteam/MPI/openmpi/5.0.1-SLES15/intel-2023.2.1-ifx/lib/libmpi_usempi_ignore_tkr.so.40 (0x000014c7e4843000) libmpi_mpifh.so.40 => /discover/swdev/gmao_SIteam/MPI/openmpi/5.0.1-SLES15/intel-2023.2.1-ifx/lib/libmpi_mpifh.so.40 (0x000014c7e47ce000) libmpi.so.40 => /discover/swdev/gmao_SIteam/MPI/openmpi/5.0.1-SLES15/intel-2023.2.1-ifx/lib/libmpi.so.40 (0x000014c7e43e0000) libimf.so => /usr/local/intel/oneapi/2021/compiler/2023.2.1/linux/compiler/lib/intel64_lin/libimf.so (0x000014c7e3ff6000) libm.so.6...

I do see in the configure output: ``` **** libxml2 configuration checking for LIBXML2... yes checking for libxml/parser.h... yes checking for xmlNewDoc... yes checking for final LIBXML2 support... yes ****...

Yes, I am running from a SLURM allocation. On our cluster at least, MPI jobs aren't allowed on head nodes (or shouldn't be allowed if somehow you manage to do...

@hppritcha Indeed, I'm going to try this with Intel tomorrow (this afternoon at work got a bit...explody). My hope is that this is a fix for our system! :)

Huzzah! Note to @hppritcha and @jvgeiger if I add `--disable-libxml2` things work for Intel 2021.6 as well (at least my small reproducer). I'm doing full builds of my stack with...

I think we are good. Both GCC and Intel seem to be good now with `--disable-libxml2`. I'll close this and #12400

@DennisHeimbigner Well that is...weird. I mean, one machine is NCCS Discover (SLES12) and the other is a MacBook Pro (macOS Ventura). Neither are big-endian at all, and my Baselibs has...

Huh. Well from the hdf4 (and hdf5 and netcdf) configure: ``` checking whether byte ordering is bigendian... no ``` so autotools is quite satisified this is a big-endian system. My...

Well, I managed to show oddities with `hdp` and asked the HDF Group here: https://forum.hdfgroup.org/t/weird-hdf4-behavior-on-macos/11603