Error when running configure during install of HDF5; missing dummy main

Here’s one workaround solution that may work for you:

export CC=$MPICC
export FC=$MPIFC
export CXX=$MPICXX
export F90=$MPIF90
export F77=$MPIF77
pip install cmake # This will install recent cmake that works for HDF5.
export PATH=/home/u177454/.local/lib/python3.9/site-packages/cmake/data/bin:$PATH
cmake -D HDF5_BUILD_FORTRAN:BOOL=ON ..

The above worked until it had some issue with linking compression library. It did not complain during configuration, at least.

[ 24%] Linking C shared library ../bin/libnull_vol_connector.so
[ 24%] Built target null_vol_connector
[ 24%] Building C object test/CMakeFiles/cache.dir/cache.c.o
[ 24%] Linking C executable ../bin/cache
../bin/libhdf5.so.303.0.0: undefined reference to `compress2'
../bin/libhdf5.so.303.0.0: undefined reference to `inflate'
../bin/libhdf5.so.303.0.0: undefined reference to `inflateInit_'

Another possibility is to use

spack install hdf5+fortran%oneapi@2022.2.1

, which I’m currently testing now.

Please consider donation if you like our fast response. :slight_smile:

The config.log posted above suggests this bug is in play:

Note the solution in the very last message in that thread (2020 Dec. 8). Now, configure here was built by autoconf 2.69 and included as part of the HDF5 1.13.2 source release. The best solution is to update to autoconf 2.70 or later, before constructing the next release.

The HDF5 team could also release a rebuilt configure to apply to 1.13.2, or users could be instructed on how to run autoconf and fix configure for themselves.

[Edit: corrected typo in autoconf version number above.]

3 Likes

If you use develop branch,

cmake -D HDF5_BUILD_FORTRAN:BOOL=ON -D HDF5_ENABLE_PARALLEL:BOOL=ON ..

worked fine with Intel oneAPI. :muscle:

[100%] Linking Fortran executable ../../bin/testhdf5_fortran
[100%] Building Fortran object fortran/test/CMakeFiles/fortranlib_test_F03.dir/fortra\
nlib_test_F03.F90.o
[100%] Linking Fortran executable ../../bin/fortranlib_test_F03
[100%] Built target testhdf5_fortran
[100%] Built target fortranlib_test_F03
[100%] Linking Fortran executable ../../../bin/hl_f90_tstlite
[100%] Built target hl_f90_tstlite

I’m now running make test to see how many tests will fail.

@dave.allured, thank you so much for sharing the issue!

Our Intel oneAPI support is only 91% good. So, please use it with caution.

          Start 2476: HL_FORTRAN_test-clean-objects
2480/2480 Test #2476: HL_FORTRAN_test-clean-objects ...............................\
...............   Passed    0.03 sec

91% tests passed, 227 tests failed out of 2480

Here are some sample test failures related to Fortran.

        2458 - MPI_TEST_f90_ex_ph5example (Failed)
	2469 - MPI_TEST_FORT_parallel_test (Failed)
        2470 - MPI_TEST_FORT_subfiling_test (Failed)

Please support us so that we can achieve 100% for oneAPI. PR requests from community are always welcome, too!

Yes, that makes sense. I am not very familiar with cmake. But I think it does not use autoconf, thereby completely avoiding the -loopopt bug.

We probably won’t update the configure file in released 1.13.x versions since those are basically glorified release candidates for 1.14.0.

I’m hesitant to bump the Autoconf version to 2.70 since it was just released in late 2020 (2.69 is circa 2012). A lot of the systems we support are fairly conservative about updating, so that might result in more headaches than a bug in a beta version of HPC Toolkit.

For now, if reconfiguring w/ Autoconf 2.70 is an acceptable work-around, just run autogen.sh in the source root to rebuild the Autotools files and go from there (or use CMake). On our end, we’ll look into generating the Autotools files for 1.14.0 w/ Autoconf 2.70+ and bumping the Autoconf version. I’m actually thinking about removing Autotools support entirely after 1.14.0 is released, so this may be a non-issue in the future (there will be a blog post about this next week).

As for OneAPI, I’d be thrilled to have better support for that in HDF5 if we’re currently deficient. Please create issues in GitHub (or, even better, send us PRs for fixes!) for anything that fails or could be improved and we’ll do our best to address them.

As you mentioned some of your systems are fairly conservative in updating systems. So many system admins may not be versed in cmake as it acts like a completely different language.

If you do go the route of switching to cmake only you will probably need an in depth setup instructions for first time users.

Personally I hate anything that uses cmake because it feels like a glorified skin over ./configure scripts.

I understand your concern and felt the same way, too!
I like the OpenBSD way of having one Makefile and just run make.
The biggest problem of CMake is that it has too many dependencies.

By the way, I was happy to see GrADS being used in the attached build script.
I’m also curious how GrADS will compile and work under Intel oneAPI.
Please let me know how the GrADS installation goes.
I want to update http://hdfeos.org/software/grads.php page accordingly.

We are using opengrads becuase when I built the script I think Grads has a paywall.

IF that isn’t the case please let me know how to download it.

What is “paywall”? :thinking:
I haven’t used both opengrads and grads for a while.
I just want to learn from you whether they can be built successfully or not with oneAPI + latest HDF5/netCDF/GRIB/etc.

I was thinking a different software.

Paywall means that you have to pay to use the software.

@hatheway.will, “GrADS is free software.” It always has been.
http://cola.gmu.edu/grads/downloads.php

1 Like

@derobins, in this context, Autoconf is used only as a developer-side tool to auto-generate the release version of the configure file. My understanding is that no downstream dependency on a specific Autoconf version is created. When the released configure file is sufficient, users should never need to run Autoconf for any routine reason, or have a specific version installed on their side.

Therefore I think you are safe to use a newer Autoconf version for constructing releases, with no downstream consequences. If I have missed something, please let us know.

1 Like

@dave.allured - Yes, that is correct. We can bump the Autoconf version for generating configure in our release branches, no problem. What I am hesitant about is bumping AC_PREREQ in configure.ac as many people on older systems build the HDF5 develop branch from source. We don’t commit Autotools generated files until we create a release branch, so those people would, in fact, have to run Autoconf.

I think dropping GNU atuotools is the way to go as GDAL did:

https://hdfeos.org/forums/showthread.php?t=875

1 Like

@dave.allured @hyoklee @derobins @jiaoxiaohuiwork

Did 1.14 fix the issue with Intel that was brought up here in the thread?

@hatheway.will, I think it’s fixed:

Here’s how I ran oneAPI compiler.

Just tried it again and it gives me the same errors as my post I put in this morning.

Maybe you can see where I went wrong?

See Parallel and C++ options are mutually exclusive?