I was able to build the dll, many thanks Michael! I hope you can
integrate your changes with the current code.

Regards,
Ing. Rodolfo Bonnin.

2011/4/1 Rodolfo Bonnin <[email protected]>:
> Great Michael!
>
> I'll research about these changes, I agree that now the hdf developers
> are aware of the problem and a solution for them.
>
> Many thanks and regards.
>
> 2011/4/1 Michael Jackson <[email protected]>:
>> And further for MinGW inside of test/CMakeLists.txt at about line 27
>> you will need to insert the following block to get the tests to
>> successfully compile against DLLs:
>> IF (MINGW)
>>    target_link_libraries(${HDF5_TEST_LIB_TARGET} "wsock32")
>> ENDIF(MINGW)
>>
>> I have been able to get the tests to compile. Started the run and some
>> are passing and some are failing. At this point it may be debuggable
>> by the HDF engineers.
>>
>>  I used the Qt SDK from Trolltech (Nokia), setup a custom batch file
>> to initialize all the paths, invoked cmake-gui.exe from a command
>> prompt and configured for MinGW Makefiles.
>> _________________________________________________________
>> Mike Jackson                  [email protected]
>> BlueQuartz Software                    www.bluequartz.net
>> Principal Software Engineer                  Dayton, Ohio
>>
>>
>>
>> On Fri, Apr 1, 2011 at 3:29 PM, Michael Jackson
>> <[email protected]> wrote:
>>> 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                  [email protected]
>>> BlueQuartz Software                    www.bluequartz.net
>>> Principal Software Engineer                  Dayton, Ohio
>>>
>>>
>>>
>>> On Fri, Apr 1, 2011 at 11:23 AM, Michael Jackson
>>> <[email protected]> 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 <[email protected]>:
>>>>>> 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 <[email protected]>:
>>>>>>>> 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       [email protected]
>>>>>>>> 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
>>>>>>>>> [email protected]
>>>>>>>>> www.suremptec.com
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Hdf-forum is for HDF software users discussion.
>>>>>>>>> [email protected]
>>>>>>>>> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Hdf-forum is for HDF software users discussion.
>>>>>>>> [email protected]
>>>>>>>> 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
>>>>>>> [email protected]
>>>>>>> www.suremptec.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Hdf-forum is for HDF software users discussion.
>>>>>>> [email protected]
>>>>>>> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Hdf-forum is for HDF software users discussion.
>>>>>> [email protected]
>>>>>> 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
>>>>> [email protected]
>>>>> www.suremptec.com
>>>>>
>>>>> _______________________________________________
>>>>> Hdf-forum is for HDF software users discussion.
>>>>> [email protected]
>>>>> http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Hdf-forum is for HDF software users discussion.
>> [email protected]
>> 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
> [email protected]
> www.suremptec.com
>



-- 
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
[email protected]
www.suremptec.com

_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

Reply via email to