Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1973 _USE_32BIT_TIME_T issue.

WSL
pending
Earnie Boyd
None
Bug
fixed
Feature_in_WSL_4.0
False
2013-06-26
2013-05-16
Earnie Boyd
No

Related

Issues: #1975
Issues: #1984

Discussion

1 2 3 .. 9 > >> (Page 1 of 9)
  • Jan Nijtmans
    Jan Nijtmans
    2013-05-22

    I looked at your patch, for example:

    #if MSVCRT_VERSION >= 800
    #define _USE_32BIT_TIME_T 1
    #endif /* MSVCRT_VERSION >= 800 */
    

    I don't think that any mingw header should set _USE_32BIT_TIME_T.

    See: http://msdn.microsoft.com/en-us/library/1f4c8f33%28v=vs.80%29.aspx

    From this page:

    In Visual C++ 2005, time is a wrapper for _time64 and time_t is, by
    default, equivalent to __time64_t. If you need to force the compiler
    to interpret time_t as the old 32-bit time_t, you can define
    _USE_32BIT_TIME_T.

    Regards,
    Jan Nijtmans

     
    Last edit: Earnie Boyd 2013-05-22
    • Earnie Boyd
      Earnie Boyd
      2013-05-22

      I don't think that any mingw header should set _USE_32BIT_TIME_T

      I agree. I have already removed it from my working area.

       
  • Twylite
    Twylite
    2013-05-22

    Following on from earnie's comments on the bug reported against Tcl: much of the confusion here seems to derive from not respecting the distinction between the C runtime library and headers, and the platform (WIN32/WIN64) libraries and header.

    If you are linking against MSVCRT.DLL (which is the C runtime) then you must compile against the corresponding headers (which don't understand and thus ignore _USE_32BIT_TIME_T). If you are compiling against headers for MSVCRT80 then you must link against MSVCRT80.

     
  • Jan Nijtmans
    Jan Nijtmans
    2013-05-22

    Here (See: mingw.patch) is my attempt to bring this issue forward. With this patch against today's git dev-4.0, Tcl 8.6 and earlier again compile fine without problems. I'm sure that it still contains problems, but for Tcl it works. The patch
    expects _HAVE_32BIT_TIME_T to be set when linking against MSVCRT80.dll or higher, _HAVE_32BIT_TIME_T should not be defined when linking against MSVCRT.dll. You will probably want to replace that with checks like "MSVCRT_VERSION >= 800".

    Regards,
    Jan Nijtmans

     
    Attachments
    • Earnie Boyd
      Earnie Boyd
      2013-05-22

      With this patch against today's git dev-4.0, Tcl 8.6 and earlier again compile fine without problems.

      Did you test on XP, the executable?

      The patch expects _HAVE_32BIT_TIME_T to be set when linking against MSVCRT80.dll or higher, _HAVE_32BIT_TIME_T should not be defined when linking against MSVCRT.dll. You will probably want to replace that with checks like "MSVCRT_VERSION >= 800".

      I'm removing the _HAVE_32BIT_TIME_T in favor of MSVCRT_VERSION; that change is in my working area, yet to be committed.

       
    • Earnie Boyd
      Earnie Boyd
      2013-05-22

      Is this the same patch as you added to the TCL ticket? If so, I've already tested it on XP and it did not work. The only thing I received during testing were SEGV errors.

       
  • Earnie Boyd
    Earnie Boyd
    2013-05-22

    Re: Twylite,

    2nd attempt, 500 error with the first.

    The issue is MSVCRT.DLL on XP does not contain the functions for _USE_32BIT_TIME_T. If _USE_32BIT_TIME_T is defined and one builds on a system whose MSVCRT.DLL supports the functions of _USE_32BIT_TIME_T and distributes that executable to someone using XP the XP user will have a sad experience. The issue with TCL is that the win/tclWinPort.h file sets _USE_32BIT_TIME_T explicitly. This causes the XP user to need to add -lmsvcr80 to build the application on XP while the Vista user could build TCL and execute it without -lmsvcr80 assuming the imports for the functions are added to libmsvcrt.a.

    Eventually I hope to resolve the issue in a later version of the MinGW runtime.

     
  • Jan Nijtmans
    Jan Nijtmans
    2013-05-22

    No, it's not the same patch as attached to the Tcl issue. I only tested it on Windows 7, but it should not use Win7-specific functions.

     
    • Earnie Boyd
      Earnie Boyd
      2013-05-22

      But _USE_32BIT_TIME_T is Vista and above specific for MSVCRT.DLL. If you take your executable to XP and try to execute it, you will not be able to.

       
  • Jan Nijtmans
    Jan Nijtmans
    2013-05-23

    With my patch (mingw.patch, attached here):
    $ nm tcl84.dll|grep I|grep time
    6297a6a0 I impftime
    6297a6b0 I __imp
    timezone
    6297a6b4 I imputime
    6297a6bc I __imp
    wutime
    6297a714 I impgmtime
    6297a71c I implocaltime
    6297a734 I impmktime
    629719e0 b _timeInfo

    Tcl doesn't use any of the "stat" functions, but this is
    what I expect for the "time"-related functions.

    Now, doing exactly the same with unpatched wsl-4.0-rc1 headers:
    $ nm tcl84.dll|grep I|grep time
    6297a6a0 I impftime64
    6297a6a4 I __imp
    gmtime64
    6297a6b0 I implocaltime64
    6297a6b4 I __imp
    mktime64
    6297a6bc I imptimezone
    6297a6c0 I __imp
    utime
    6297a6c8 I imp___wutime
    629719e0 b _timeInfo

    Which means that _USE_32BIT_TIME_T didn't do what it's
    supposed to do. It's wrong. mktime64 didn't exist in
    Win95/ME, so Tcl 8.4 wouldn't run there any more.

     
1 2 3 .. 9 > >> (Page 1 of 9)