h5check fails to build

[Former user]

When compiling the toolkit using the bundled version of the HDF5 library, the thorn fails to compile and blocks the rest of the compilation process.

Specifically, the main library, distributed as "hdf5-1.12.0.tar.gz" compiles fine but the additional component "h5check_2_0.tar.gz" fails to build (using gcc 8.3) due to multiple definitions of the type "error_t". It seams that h5check defines this type which conflicts with cstdlib's own error_t.

Since this type is used in only three places, I've managed to fix the bug by replacing "error_t" in the source files with "h5_error_t". I'm sending the "corrected" source file attached.

I've observed the bug in release 2020/05 but I think that any release that uses h5check version 1.12.0 may also show this behavior

[Lucas Timotheo Sanches]

I’m the one who posted this issue. I’ve forgot to login before doing it and now it’s assigned to this anonymous user. I’m really sorry for that

[Roland Haas]

I just tried and I can successfully build the included h5check in ET_2020_11 on Debian Buster (10) which uses gcc-8.3. I can also build the unmodified tarball h5check_2_0.tar.gz on that system, so as far as I can tell gcc 8.3 should compile it.

Can you please include the exact compiler output as an attachment? Something like:

simfactory/bin/sim build 2>&1 sim | tee make.log 

and then the output (including all errors) will be in make.log. Similarly if you do not use simfactory. Please also include the file configs/sim/config-info which contain all the make options used.

The file h5check_2_0.tar.gz has not changed for 9 years so all releases in that time would show this effect.

Note that having multiple (even identical) typedefs for the same type is indeed an error in C99 (only stops being so in C11). https://stackoverflow.com/a/8595131 In my experience (having assumed it would be ok) the GNU compiler does actually accept it even in C99 (possible b/c C++ does allow it). Are you setting any of the “pedantic” or strict-ansi-conformance options (though even with -pedantic -std=c99I could not make the build fail)?

[Roland Haas]

Also, looking at your description once more. Since the conflict is with an error_t typedef in you glibc’s error_t.h file (used in errno.h it seems) can you let me know which OS you are trying this on?

We can certainly include patch `h5_error.h` in the way you fixed in future releases.

[Roland Haas]

ok, I can make it fail if I define _GNU_SOURCE eg if you had CPPFLAGS=-D_GNU_SOURCE you’d get that error. Is that what you have?

[Lucas Timotheo Sanches]

The error shows up on line 14235

[Lucas Timotheo Sanches]

Hey Roland, sorry for the delay. Looks like the culprit is indeed CPPFLAGS=-D_GNU_SOURCE. Here are my compiler flags from simfactory’s optionlist file:

CFLAGS   = -g -std=gnu11 -D_GNU_SOURCE -fcommon
CXXFLAGS = -g -std=gnu++11 -fcommon -fpermissive
F90FLAGS = -g -fcray-pointer -ffixed-line-length-none

I’m quite sure I’ve got this flag from one of the tutorials in the official site, but now I cant seem to find the exact page that recommends it . I’ve managed to use the toolkit successfully with it for some time now but always with the system provided HDF5. I’ve decided to try the bundled version to solve an error that in the end hadn't anything to do with the HD5F lib being used and stumbled upon this.

Also, as you’ve asked, my output of cat /etc/os-release

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

and gcc --version

gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

‌

[Roland Haas]

Ok, that explains it then. I have adapted your fix and pushed it as git hash 7090973 "HDF5: make h5check compile even if _GNU_SOURCE is defined" of ExternalLibraries-HDF5

I cannot find where _GNU_SOURCE shows up in the docs or tutorials either, but it is used in a couple of simfactory option lists (which all use a system compiled HDF5 library) so having the fix is a good idea anyway just in case we ever need to build our own HDF5 library on those machines.

You already seem to have a workaround, alternatively I would have suggested compiling without -D_GNU_SOURCE which ought not be required, in particular if you already use -std=gnuc11 and -std=gnu++11 anyway.

[Lucas Timotheo Sanches]

Nice! Good to know my workaround was of some use.

In the future I’ll try and stop using -D_GNU_SOURCE then. Thanks!