autogen.sh fails

[jeffhammond]

I do not understand why autogen.sh breaks on a very generic Linux machine.

autoreconf -fiv works just fine, so perhaps that should be documented as a superior option.

Error

jhammond@nuclear:~/HDF5/git$ ./autogen.sh -v

**************************
* HDF5 autogen.sh script *
**************************

Setting verbosity: high

dirname: missing operand
Try 'dirname --help' for more information.
Running trace script:
Finished processing HDF5 API calls:
	instrumented 0 API functions and 0 argument lists

Running error generation script:
Generating 'H5Epubgen.h'
Generating 'H5Einit.h'
Generating 'H5Eterm.h'
Generating 'H5Edefin.h'

Running API version generation script:
Generating 'src/H5version.h'

Running overflow macro generation script:
Generating 'H5overflow.h'

/libtoolize --copy --force
./autogen.sh: 254: /libtoolize: not found
./autogen.sh: 256: /libtoolize: not found

/usr/bin/libtoolize is present in the obvious default, so I do not know why it's not found.

Version

jhammond@nuclear:~/HDF5/git$ git log -n1
commit 9e6de287e7dee1f504f7c9cd7bfe32d8b349ee04 (HEAD -> develop, origin/develop, origin/HEAD)
Author: jhendersonHDF <[email protected]>
Date:   Tue Jan 4 11:00:55 2022 -0600

    Fix usage of several HDfprintf format specifiers after HDfprintf removal (#1324)

jhammond@nuclear:~/HDF5/git$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Machine

jhammond@nuclear:~/HDF5/git$ uname -a
Linux nuclear 5.11.0-44-generic #48~20.04.2-Ubuntu SMP Tue Dec 14 15:36:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[jhendersonHDF]

At first glance:

/libtoolize --copy --force

seems to be the issue. libtoolize certainly isn't going to be found there unless you have a strange system!

Looks like autogen.sh had a problem running dirname, which in turn causes LIBTOOL_DIR to be unset here. Is the output from which libtool on your system what you'd expect?

[jeffhammond]

The issue is that libtool wasn't installed, because it comes from libtool-bin, whereas I only had the libtool package.

This happened to me on both of my Ubuntu 20 machines, both of which have the dependencies for all the HPC software I use, and I build e.g. LLVM and NWChem on them all the time, so they have the standard development packages installed.

I recommend more defense programming w.r.t. the following:

HDF5_LIBTOOL=$(which libtool)
..
LIBTOOL_DIR=`dirname ${HDF5_LIBTOOL}`
..
HDF5_LIBTOOLIZE="${LIBTOOL_DIR}/libtoolize"

[jhendersonHDF]

I recommend more defense programming w.r.t. the following

Agreed on this. It looks like we only use libtool to find the directory for libtoolize, so it may be fine to just do a which libtoolize instead. @derobins thoughts?

[derobins]

It's been a long time since I looked at this code, but yeah - libtool-bin has to be installed. We can change it, we just have to be mindful of not breaking other platforms. I recall MacOS requiring hacks.

FWIW, we cobbled together a custom script instead of just running autoreconf because of older systems we had to support and the desire to hard-code the autotools versions we used to release. Those requirements may not be valid today, so it's probably worth revisiting that.

[derobins]

We had to (temporarily) revert this change as it's breaking the NAG Fortran compiler and we have a release to get out the door.

[derobins]

It's probably too late to get this into 1.14.3, but I'll try to merge #1906 back in and address the NAG Fortran issues for 1.14.4.