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

HDF5 Library
1

My colleague and I are trying to install HDF5 as part of a larger WRF (Weather Research and Forecasting) model install, and running into a problem at the configure step that’s defied our debugging efforts. Unfortunately since this is a new account, I can’t upload the relevant logs and script code, but people that want to look at them can pm me, and we can work it out. I’ll at least paste what seems to us to be the key log file and script code:

configure.log:
checking for dummy main to link with Fortran libraries… unknown
configure: error: in ‘/home/work/WRF-HYDRO_Intel/Downloads/hdf5-hdf5-1_13_2’:
configure: error: linking to Fortran libraries from C fails
See `config.log’ for more details

config.log:
“/usr/bin/ld” -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/11/crtbegin.o -L/opt/intel/oneapi/mpi/2021.7.1/lib/release -L/opt/intel/oneapi/mpi/2021.7.1/lib -L/opt/intel/oneapi/compiler/2022.2.1/linux/bin-llvm/…/compiler/lib/intel64_lin -L/opt/intel/oneapi/compiler/2022.2.1/linux/bin-llvm/…/lib -L/opt/intel/oneapi/compiler/2022.2.1/linux/bin-llvm/…/compiler/lib/intel64_lin -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/usr/lib/gcc/x86_64-linux-gnu/11/…/…/…/…/lib64 -L/lib/x86_64-linux-gnu -L/lib/…/lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/…/lib64 -L/usr/lib/gcc/x86_64-linux-gnu/11/…/…/… -L/lib -L/usr/lib -L/opt/intel/oneapi/vpl/2022.2.5/lib -L/opt/intel/oneapi/tbb/2021.7.1/env/…/lib/intel64/gcc4.8 -L/opt/intel/oneapi/mpi/2021.7.1//libfabric/lib -L/opt/intel/oneapi/mpi/2021.7.1//lib/release -L/opt/intel/oneapi/mpi/2021.7.1//lib -L/opt/intel/oneapi/mkl/2022.2.1/lib/intel64 -L/opt/intel/oneapi/ipp/2021.6.2/lib/intel64 -L/opt/intel/oneapi/ippcp/2021.6.2/lib/intel64 -L/opt/intel/oneapi/ipp/2021.6.2/lib/intel64 -L/opt/intel/oneapi/dnnl/2022.2.1/cpu_dpcpp_gpu_dpcpp/lib -L/opt/intel/oneapi/dal/2021.7.1/lib/intel64 -L/opt/intel/oneapi/compiler/2022.2.1/linux/compiler/lib/intel64_lin -L/opt/intel/oneapi/compiler/2022.2.1/linux/lib -L/opt/intel/oneapi/clck/2021.7.1/lib/intel64 -L/opt/intel/oneapi/ccl/2021.7.1/lib/cpu_gpu_dpcpp --enable-new-dtags -rpath /opt/intel/oneapi/mpi/2021.7.1/lib/release -rpath /opt/intel/oneapi/mpi/2021.7.1/lib -lmpifort -lmpi -ldl -lrt -lpthread -Bstatic -lsvml -Bdynamic -Bstatic -lirng -Bdynamic -Bstatic -limf -Bdynamic -lm -lgcc --as-needed -lgcc_s --no-as-needed -Bstatic -lirc -Bdynamic -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed -Bstatic -lirc_s -Bdynamic /usr/lib/gcc/x86_64-linux-gnu/11/crtend.o /lib/x86_64-linux-gnu/crtn.o
… rest of stderr output deleted …
configure:4855: $? = 1
configure:4844: mpiicc -cc=icx -V >&5
Intel® oneAPI DPC++/C++ Compiler for applications running on Intel® 64, Version 2022.2.1 Build 20221020
Copyright © 1985-2022 Intel Corporation. All rights reserved.

/usr/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function ‘_start’:
(.text+0x1b): undefined reference to `main’
icx: error: linker command failed with exit code 1 (use -v to see invocation)
configure:4855: $? = 1

We’ve double-checked the existence of the libraries in the source and build directories, so it should be finding them (and therefore the dummy main) but it’s still not for some reason.

our bash script:
…
export MPIFC=‘mpiifort -fc=ifx’
export MPIF77=‘mpiifort -fc=ifx’
export MPIF90=‘mpiifort -fc=ifx’
export MPICC=‘mpiicc -cc=icx’
export MPICXX=‘mpiicpc -cxx=icpx’

…

export HOME=cd;pwd
export WRF_FOLDER=$HOME/WRF-HYDRO_Intel
export DIR=$WRF_FOLDER/Libs

…

CC=$MPICC FC=$MPIFC CXX=$MPICXX F90=$MPIF90 F77=$MPIF77 CFLAGS="-fPIC -fPIE -diag-disable=10441" ./configure --prefix=$DIR/grib2 --with-zlib=$DIR/grib2 --enable-hl --enable-fortran --enable-parallel |& tee configure.log

…

(Ellipses indicate snipped code)

Please note that we previously had the entire script running perfectly when using the gcc/gfortran compilers, and this current problem comes as we’re testing the install process using the new Intel compilers (icx, icpx, and ifx), so bugs or other errors are expected.

If someone here can give us some insight into what’s going wrong here, that’d help us get to the root of the issue.

Thanks for your time!

1 Like
2

Hi, @mkr39-b, thank you so much trying HDF5 on Intel OneAPI :clap: since I was very curious how HDF5 will behave!

Yes, I’m interested in checking them.

Also, is your compiler environment easily reproducible through Intel DevCloud?
Then, I’d appreciate if you can explain how to replicate your set-up there.
Alternatively, you can attach your bash script that can be submitted for qsub build.

Here’s what I got on HDF5 1.13.3 during configuration:


    checking how mpiifort -fc=ifx finds modules... -I
./configure: line 7345: $'\357\277\274': command not found
o -lirc -lirc_s
checking for dummy main to link with Fortran libraries... unknown
configure: error: in `/home/u177454/hdf5-hdf5-1_13_3':
configure: error: linking to Fortran libraries from C fails
See `config.log' for more details

The below is common error inside config.log.

Intel(R) oneAPI DPC++/C++ Compiler for applications running on Intel(R) 64, Version 20\
22.2.1 Build 20221020
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

/usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
icx: error: linker command failed with exit code 1 (use -v to see invocation)
configure:4856: $? = 1
configure:4845: mpiicc -cc=icx -qversion >&5
icx: error: unknown argument '-qversion'; did you mean '--version'?

onfigure:5653: mpiicc -cc=icx -E   conftest.c
conftest.c:11:10: fatal error: 'ac_nonexistent.h' file not found
#include <ac_nonexistent.h>
         ^~~~~~~~~~~~~~~~~~
1 error generated.

configure:6000: mpiicc -cc=icx -c  -fPIC -fPIE -diag-disable=10441   conftest.c >&5
conftest.c:57:20: error: expected expression
if (sizeof ((off_t)))
                   ^
1 error generated.

configure:6037: mpiicc -cc=icx -c  -fPIC -fPIE -diag-disable=10441   conftest.c >&5
conftest.c:22:9: error: unknown type name 'not'
               not a universal capable compiler
               ^
conftest.c:22:14: error: expected ';' after top level declarator
               not a universal capable compiler
                    ^
                    ;
2 errors generated.

configure:6594: mpiicc -cc=icx -o conftest  -fPIC -fPIE -diag-disable=10441     conft\
est.c  >&5
conftest.c:64:57: error: use of undeclared identifier '_Quad'
static long int longval () { return (long int) (sizeof (_Quad)); }
                                                        ^
configure:6620: mpiicc -cc=icx -c  -fPIC -fPIE -diag-disable=10441   conftest.c >&5
conftest.c:65:10: fatal error: 'quadmath.h' file not found
#include <quadmath.h>
         ^~~~~~~~~~~~
1 error generated.
configure:6620: $? = 1

configure:6907: mpiifort -fc=ifx -c    conftest.F >&5
conftest.F(3): error #5082: Syntax error, found END-OF-STATEMENT when expecting one o\
f: ( : % [ . = =>
       choke me
---------------^
conftest.F(3): error #6218: This statement is positioned incorrectly and/or has synta\
x errors.
       choke me
-------^
compilation aborted for conftest.F (code 1)


/usr/bin/ld: cannot find -loopopt=1
icx: error: linker command failed with exit code 1 (use -v to see invocation)
configure:7766: $? = 1

I hope the above output matches what you got.

3

I can easily send you the script and log files; just let me know an email address I can send them to, since I can’t upload yet.

As for Intel DevCloud, neither me nor my colleague have ever used it before; do you know whether it’s a free or paid service?

What aspects of the compiler environment do you want to know about? We can probably look into them and report back to you.

Our setup is very basic: it’s a fresh, clean install of Ubuntu (we’re currently using 22.04.1), with nothing else done to it before we run our script. The necessary environment variables should all be set within the script.

4

unfortunately we cannot attach our scripts since we do not have the permissions to do so on the forum since we are new users.

5

@mkr39-b - I made you a basic user so you should be able to upload your config.log file now.

6

Ah, thank you very much!

I managed to send him the files via email, but I’ll make sure to upload files here in the future as needed. I guess I should probably upload these files here just in case others happen to find this post and are interested.

configure.log (6.3 KB)
libpng.makeinstall.log (6.1 KB)
libpng.make.log (27.0 KB)
WRFHYDRO-Coupled-Install-Script-Linux-64bit-Intel_relevant.sh (14.5 KB)
zlib.makeinstall.log (985 Bytes)
config.log (138.4 KB)
zlib.make.log (90.6 KB)

7

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:

8

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
9

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.

10

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

11

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!

12

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.

13

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.

14

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.

15

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.

16

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.

17

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.

18

I was thinking a different software.

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

19

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

1 Like
20

@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