So I did some digging into HDF5 1.8 CMake and MinGW and here is what I
came up with. There are some basic errors in the CMake file at
config/cmake/ConfigureChecks.cmake. Namely there is a section that
says:
SET (WINDOWS)
IF (WIN32)
IF (NOT UNIX AND NOT CYGWIN)
SET (WINDOWS 1)
ENDIF (NOT UNIX AND NOT CYGWIN)
ENDIF (WIN32)
The problem is that on MinGW the "WINDOWS" variable will be set to 1
which has bad ramifications about what is available on the system
later on in the file. So we change that to this:
SET (WINDOWS)
IF (WIN32)
IF (NOT UNIX AND NOT CYGWIN AND NOT MINGW)
SET (WINDOWS 1)
ENDIF (NOT UNIX AND NOT CYGWIN AND NOT MINGW)
ENDIF (WIN32)
Then later on in that file there is an "IF (NOT WINDOWS)" block
starting at line 551. That needs to be changed to the following:
IF (NOT WINDOWS)
FOREACH (test
TIME_WITH_SYS_TIME
STDC_HEADERS
HAVE_TM_ZONE
HAVE_STRUCT_TM_TM_ZONE
HAVE_ATTRIBUTE
HAVE_FUNCTION
HAVE_TM_GMTOFF
HAVE_STRUCT_TIMEZONE
HAVE_STAT_ST_BLOCKS
HAVE_FUNCTION
SYSTEM_SCOPE_THREADS
HAVE_SOCKLEN_T
DEV_T_IS_SCALAR
HAVE_OFF64_T
GETTIMEOFDAY_GIVES_TZ
VSNPRINTF_WORKS
HAVE_C99_FUNC
HAVE_C99_DESIGNATED_INITIALIZER
CXX_HAVE_OFFSETOF
LONE_COLON
)
HDF5_FUNCTION_TEST (${test})
ENDFOREACH (test)
IF (NOT CYGWIN AND NOT MINGW)
HDF5_FUNCTION_TEST (HAVE_TIMEZONE)
ENDIF (NOT CYGWIN AND NOT MINGW)
ENDIF (NOT WINDOWS)
Note that for MinGW we are NOT checking for 'timezone' as a previous
test for HAVE_STRUCT_TIMEZONE passes.
Note that at line 509 (FOREACH block) has an error in it and it should be this:
FOREACH (def
HAVE_SYS_TIME_H
HAVE_UNISTD_H
HAVE_SYS_TYPES_H
HAVE_SYS_SOCKET_H
)
IF ("${H5_${def}}")
SET (MACRO_CHECK_FUNCTION_DEFINITIONS
"${MACRO_CHECK_FUNCTION_DEFINITIONS} -D${def}")
ENDIF ("${H5_${def}}")
ENDFOREACH (def)
so it matches HDF5Tests.c which also has some tweaks that need to be fixed.
SOOOOO after all of that we get down to what is going on with MinGW.
MinGW does in fact have a sys/time.h file which has this declaration:
/* Provided for compatibility with code that assumes that
the presence of gettimeofday function implies a definition
of struct timezone. */
struct timezone
{
int tz_minuteswest; /* of Greenwich */
int tz_dsttime; /* type of dst correction to apply */
};
Note that this is a "Declaration" and NOT a definition so no memory is
actually reserved for the "timezone" struct. But with the above
changes to the CMake files and if you reconfigure with CMake on a
CLEAN build directory you should be able to now get MinGW to compile
HDF5 1.8.
Now here is the part I don't understand. On MinGW the following will compile:
#include <sys/time.h>
int main()
{
timezone = 0;
return 0;
}
which if we actually use that as a test we get a false positive for
H5_HAVE_TIMEZONE which makes it get defined in H5pubconf.h that CMake
generates. So in the file H5Omtime.c we end up taking the wrong code
path at line 226 and somehow get a compile error although the two uses
look the same there is something different. Either way it is probably
just wrong under MinGW. With the CMake corrections all the proper
#defines get set and we take another code path in H5Omtime.c which
allows us to compile both as static and as dynamic libraries.
I have just started trying to get the tests to compile.
Since I don't know squat about svn or remember my credentials to push
up to the source code repository I'll have to figure out how to get
all the changes placed somewhere.
···
_________________________________________________________
Mike Jackson mike.jackson@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Fri, Apr 1, 2011 at 11:23 AM, Michael Jackson <mike.jackson@bluequartz.net> wrote:
For the configure side of things, I'll ask the stupid question and you did tell configure you wanted shared libraries?
For the CMake side of things, was time.h included in the file that can't find the definition? And if it _is_ included, and timezone is defined in the file what is happening during the compile process that makes "timezone" NOT defined, in other words, is there some preprocessor define that is NOT getting set properly allowing the code path in time.h to define timezone? You may have to start manually setting #error in some of the system header files to deduce what is happening. Meanwhile I'll try and pull the Qt SDK that has MinGW in it to see if I can eventually set something up. This would be a nice CDash submission.
--
Mike Jackson <www.bluequartz.net>
On Apr 1, 2011, at 11:00 AM, Rodolfo Bonnin wrote:
What is is strange is that the library compiles using configure, but
it doesn't generate the dll .
2011/4/1 Michael Jackson <mike.jackson@bluequartz.net>:
I don't have a setup where I can test this but what header file is "timezone" defined in MinGW? And is that file included at the top of H5Omtime.c? It would be nice if HDF5 would compile under MinGW if we can get this fixed.
--
Mike Jackson <www.bluequartz.net>
On Apr 1, 2011, at 10:04 AM, Rodolfo Bonnin wrote:
It is MinGW 4.4.0, the one included in the last QT SDK.
Regards
2011/4/1 Michael Jackson <mike.jackson@bluequartz.net>:
What version of MinGW are you using? Older versions of MinGW are missing standard headers related to time/date functions.
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 1, 2011, at 9:26 AM, Rodolfo Bonnin wrote:
Hello all,
I'm trying to build libhdf5 dll using msys and MinGW.
Using the configure/make method doesn't generate the dll, and after
searching for answers, it seems probable that there were no provisions
to have the dll built with that platform, althought adding this task
seems possible. How can I modify the configure script in order to add
the dll building step?
On the other hand, building with CMake, I've got the error
H5Omtime.c:226: error: 'timezone' undeclared (first use in this function)
Which I have seen can be related with the use of an ancient struct no
more available. Is there any flag I should use to avoid this error?
Many thanks in advance.
--
Ing. Rodolfo Bonnin
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina "B" (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
rodolfobonnin@suremptec.com.ar
www.suremptec.com
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
Ing. Rodolfo Bonnin
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina "B" (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
rodolfobonnin@suremptec.com.ar
www.suremptec.com
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
--
Ing. Rodolfo Bonnin
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina "B" (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
rodolfobonnin@suremptec.com.ar
www.suremptec.com
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org