Question about building HDF5 1.10.0-patch1 for vxWorks

HDF5 Library
1

Folks,

I am responsible for the software called areaDetector which provides control of 2-D detectors and other devices for the EPICS control system.

http://cars.uchicago.edu/software/epics/areaDetector.html

One of the things I have done recently is to add a new repository where the HDF5 source code is packaged in a way that allows it to be built with the EPICS build system.

This allows us to build it from source code on any platform that EPICS supports, including Windows (Visual Studio or MinGW), Linux, and vxWorks. For vxWorks this is really the only practical mechanism, since it requires cross-compiling and the normal Linux "configure" scripts won't work. The README.epics file in that repository explains exactly what I did for each platform to support this build mechanism. Supporting HDF5 on vxWorks is really desirable because that is the real-time operating system that is used in many EPICS installations for controlling VME data acquisition devices.

On vxWorks it is working in the sense that I have successfully saved HDF5 files and verified that they can be read using the h5dump utility on Linux. It is working for uncompressed files, and files with szip and zlib compression.

However, I am having one problem building H5T.c which I wonder if you might be able to help me with. If I build the unmodified version of H5T.c I get the following errors:

../H5T.c: In function 'H5T__init_package':
../H5T.c:931: error: 'H5T_INIT_TYPE_ULONG_CORE' undeclared (first use in this function)
../H5T.c:931: error: (Each undeclared identifier is reported only once
../H5T.c:931: error: for each function it appears in.)
../H5T.c:931: error: expected ';' before 'if'
../H5T.c:934: error: expected ';' before 'if'
../H5T.c:937: error: expected ';' before 'if'
../H5T.c:940: error: expected ';' before 'if'
../H5T.c: In function 'H5T_path_find':
../H5T.c:4497: warning: passing argument 1 of 'H5T_copy' discards qualifiers from pointer target type
../H5T.c:4499: warning: passing argument 1 of 'H5T_copy' discards qualifiers from pointer target type
make[1]: *** [H5T.o] Error 1
make[1]: Leaving directory `/home/epics/devel/areaDetector-2-5/ADSupport/supportApp/hdf5Src/O.vxWorks-ppc32'
make: *** [install.vxWorks-ppc32] Error 2

However, if I don't compile these 4 lines on vxWorks it builds fine:

#ifndef H5_HAVE_VXWORKS
/* These functions are not working on vxWorks, need to figure out why */
    /* Little-endian 32-bit UNIX time_t */
    H5T_INIT_TYPE(TIME, H5T_UNIX_D32LE_g, COPY, std_u32le, NOSET, -)

    /* Big-endian 32-bit UNIX time_t */
    H5T_INIT_TYPE(TIME, H5T_UNIX_D32BE_g, COPY, std_u32be, NOSET, -)

    /* Little-endian 64-bit UNIX time_t */
    H5T_INIT_TYPE(TIME, H5T_UNIX_D64LE_g, COPY, std_u64le, NOSET, -)

    /* Big-endian 64-bit UNIX time_t */
    H5T_INIT_TYPE(TIME, H5T_UNIX_D64BE_g, COPY, std_u64be, NOSET, -)
#endif

The vxWorks cross-compiler version is:

ccppc (Wind River VxWorks G++ 4.3-315) 4.3.3.

I suspect the problem is that some data type is not correctly defined on vxWorks, but I have not been able to figure out exactly what is wrong. The H5T_INIT_TYPE macro is quite deeply nested, and I am stumped.

I am hoping you might be able to tell me what would cause these 4 lines to fail to compile.

Thanks very much,
Mark

2

Hi Barbara,

HDF5 does not support cross-compiling and we have not tested with vxWorks. :frowning:

I understand that. I have created a solution which does work for cross-compiling with the EPICS build system. It is basically working for cross-compiling on both VxWorks and MinGW (compiling Windows code on Linux). There is just one minor problem I am having on VxWorks, really is unrelated to the fact that I am cross-compiling.

Normally, when you build HDF5 it tries to detect what you have and then
generates the H5Tinit.c and other files with the appropriate information. HDF5
cannot do that when cross-compiling.

I understand that as well. As I said in my original message I have carefully documented exactly how I built HDF5, including on VxWorks here:

What I did on VxWorks was to first cross-compile and build the H5detect executable. I then manually ran that on the target VxWorks system to generate H5Tinit.c. That is working fine.

The problem is only that there are 4 lines in H5T.C that do not compile. I would like help from someone more familiar with the HDF5 code to tell me what datatypes might be incompletely or incorrectly defined to generate the compile errors I am finding on those 4 lines.

Thanks,
Mark

···

-----Original Message-----
From: help@hdfgroup.org [mailto:help@hdfgroup.org]
Sent: Monday, October 10, 2016 2:34 PM
To: Mark Rivers
Subject: Re: Question about building HDF5 1.10.0-patch1 for vxWorks

Hi Mark,

HDF5 does not support cross-compiling and we have not tested with vxWorks. :frowning:

Normally, when you build HDF5 it tries to detect what you have and then
generates the H5Tinit.c and other files with the appropriate information. HDF5
cannot do that when cross-compiling.

A developer was able to get HDF5 built on android by brute force. I believe
you will have to do the same kinds of changes that he did so that HDF5 detects
the correct platform. See the attached file, android-steps.txt, for the steps he
followed.

I don't know that we use those TIME datatypes, as we do not support a time
datatype. However, it is better to resolve the issues in the configure/build
rather than changing source code files.

-Barbara

========================================================
Barbara Jones, The HDF Group Helpdesk, help@hdfgroup.org
Support Services: https://www.hdfgroup.org/services/

On Sat, 8 Oct 2016, Mark Rivers wrote:

Folks,

I am responsible for the software called areaDetector which provides control of 2-D detectors and other devices for the EPICS control system.

http://cars.uchicago.edu/software/epics/areaDetector.html
http://www.aps.anl.gov/epics/

One of the things I have done recently is to add a new repository where the HDF5 source code is packaged in a way that allows it to be built with the EPICS build system.

https://github.com/areaDetector/ADSupport

This allows us to build it from source code on any platform that EPICS supports, including Windows (Visual Studio or MinGW), Linux, and vxWorks. For vxWorks this is really the only practical mechanism, since it requires cross-compiling and the normal Linux "configure" scripts won't work. The README.epics file in that repository explains exactly what I did for each platform to support this build mechanism. Supporting HDF5 on vxWorks is really desirable because that is the real-time operating system that is used in many EPICS installations for controlling VME data acquisition devices.

On vxWorks it is working in the sense that I have successfully saved HDF5 files and verified that they can be read using the h5dump utility on Linux. It is working for uncompressed files, and files with szip and zlib compression.

However, I am having one problem building H5T.c which I wonder if you might

be able to help me with. If I build the unmodified version of H5T.c I get the following errors:

../H5T.c: In function 'H5T__init_package':
../H5T.c:931: error: 'H5T_INIT_TYPE_ULONG_CORE' undeclared (first use in this function)
../H5T.c:931: error: (Each undeclared identifier is reported only once
../H5T.c:931: error: for each function it appears in.)
../H5T.c:931: error: expected ';' before 'if'
../H5T.c:934: error: expected ';' before 'if'
../H5T.c:937: error: expected ';' before 'if'
../H5T.c:940: error: expected ';' before 'if'
../H5T.c: In function 'H5T_path_find':
../H5T.c:4497: warning: passing argument 1 of 'H5T_copy' discards qualifiers

from pointer target type

../H5T.c:4499: warning: passing argument 1 of 'H5T_copy' discards qualifiers from pointer target type
make[1]: *** [H5T.o] Error 1
make[1]: Leaving directory `/home/epics/devel/areaDetector-2-5/ADSupport/supportApp/hdf5Src/O.vxWorks-ppc32'
make: *** [install.vxWorks-ppc32] Error 2

However, if I don't compile these 4 lines on vxWorks it builds fine:

#ifndef H5_HAVE_VXWORKS
/* These functions are not working on vxWorks, need to figure out why */
   /* Little-endian 32-bit UNIX time_t */
   H5T_INIT_TYPE(TIME, H5T_UNIX_D32LE_g, COPY, std_u32le, NOSET, -)

   /* Big-endian 32-bit UNIX time_t */
   H5T_INIT_TYPE(TIME, H5T_UNIX_D32BE_g, COPY, std_u32be, NOSET, -)

   /* Little-endian 64-bit UNIX time_t */
   H5T_INIT_TYPE(TIME, H5T_UNIX_D64LE_g, COPY, std_u64le, NOSET, -)

   /* Big-endian 64-bit UNIX time_t */
   H5T_INIT_TYPE(TIME, H5T_UNIX_D64BE_g, COPY, std_u64be, NOSET, -)
#endif

The vxWorks cross-compiler version is:

ccppc (Wind River VxWorks G++ 4.3-315) 4.3.3.

I suspect the problem is that some data type is not correctly defined on

vxWorks, but I have not been able to figure out exactly what is wrong. The
H5T_INIT_TYPE macro is quite deeply nested, and I am stumped.

I am hoping you might be able to tell me what would cause these 4 lines to

fail to compile.

Thanks very much,
Mark

--

3

Hello. Massive apologies for resurrecting an old thread but I couldn’t see any other mention of vxWorks.

I am curious to know if the official position is still that HDF5 is not supported on vxWorks? I attempted to cross-compile for vxWorks before finding this thread, and it didn’t work, so I assume this is the case. But I thought best to check before giving up entirely.