Re^12: Testing Time::Piece on Windows/VC

Replies are listed 'Best First'.
Re^13: Testing Time::Piece on Windows/VC by BrowserUk (Patriarch) on Feb 02, 2010 at 08:27 UTC
Intriguing. What do you get from `dumpbin /imports Piece.dll`? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "I'd rather go naked than blow up my ass"	[reply] [d/l]
Re^14: Testing Time::Piece on Windows/VC by syphilis (Archbishop) on Feb 02, 2010 at 12:47 UTC
What do you get from dumpbin /imports Piece.dll I get: Microsoft (R) COFF/PE Dumper Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file blib/arch/auto/Time/Piece/Piece.dll File Type: DLL Section contains the following imports: perl510.dll 10004064 Import Address Table 10004690 Import Name Table 0 time date stamp 0 Index of first forwarder reference 355 Perl_newXS_flags 21A Perl_croak 4AB Perl_vstringify 4A1 Perl_vcmp 1C0 Perl_Iunitcheckav_ptr 35A Perl_new_version 262 Perl_get_sv 254 Perl_form 18C Perl_Iscopestack_ix_ptr 20F Perl_call_list 1B2 Perl_Isv_yes_ptr 3F6 Perl_sv_2nv 21B Perl_croak_nocontext 4B0 Perl_warn_nocontext 19C Perl_Istack_max_ptr 3EC Perl_stack_grow 346 Perl_newSViv 19D Perl_Istack_sp_ptr 144 Perl_Imarkstack_ptr_ptr 19B Perl_Istack_base_ptr 21C Perl_croak_xs_usage 3F8 Perl_sv_2pv_flags 3F4 Perl_sv_2iv_flags 2B5 Perl_init_tm 3A8 Perl_safesysmalloc 3A9 Perl_safesysrealloc 348 Perl_newSVpv 3F5 Perl_sv_2mortal 3A7 Perl_safesysfree 25A Perl_get_context 9A Perl_Gcurinterp_ptr 417 Perl_sv_derived_from 507 win32_getenv MSVCR70.dll 10004008 Import Address Table 10004634 Import Name Table 0 time date stamp 0 Index of first forwarder reference F5 _except_handler3 6E __dllonexit BE _adjust_fdiv 142 _initterm 204 _strnicmp 218 _tzset 1CA _putenv 2DD localtime 2BE gmtime 2E9 memset 30D strftime 2C9 isspace 2C3 isdigit 2CA isupper 311 strncpy 2BA getenv 308 strcmp 30E strlen 2E1 malloc 302 sprintf 2AE free 1BB _onexit KERNEL32.dll 10004000 Import Address Table 1000462C Import Name Table 0 time date stamp 0 Index of first forwarder reference 80 DisableThreadLibraryCalls Summary 1000 .data 1000 .rdata 1000 .reloc 3000 .text [download] On p5p, Matt wrote: `I've implemented a fix, and having people test it now, just by implementing my own version of localtime and gmtime in the module (stu +pid I know, but it works).` [download] Yet I notice that (apparently) both localtime and gmtime are still being imported from msvcr70.dll. Is that what's stuffing things up ? Cheers, Rob	[reply] [d/l] [select]
Re^15: Testing Time::Piece on Windows/VC by BrowserUk (Patriarch) on Feb 02, 2010 at 14:44 UTC
localtime and gmtime are still being imported from msvcr70.dll. Is that what's stuffing things up ? No. That's what cured the problem with tzoffset(). It means that all the CRT calls used by Time::Piece are now imported from the same version of the CRT, and therefore operate upon the CRT copy of the environment. Previously, those two were being imported from msvcrt.dll, and hence referenced its copy of the environment, while the tzset(), getenv() & putenv() were coming from msvcr70.dll and operating upon its copy. The failure you're seeing now, is with strftime() & "%Z", which fails to return the timezone name. Which is weird because dumpbin shows strftime() being imported from the right place. If the module was picking up anything from the wrong runtime, I'd have expected to see it also importing something from mscvrt.dll, but that's not the case.	[reply]
Re^16: Testing Time::Piece on Windows/VC by syphilis (Archbishop) on Feb 03, 2010 at 03:46 UTC
Re^17: Testing Time::Piece on Windows/VC by BrowserUk (Patriarch) on Feb 03, 2010 at 07:49 UTC

Intriguing. What do you get from dumpbin /imports Piece.dll?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"I'd rather go naked than blow up my ass"

What do you get from dumpbin /imports Piece.dll

Microsoft (R) COFF/PE Dumper Version 7.00.9466
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file blib/arch/auto/Time/Piece/Piece.dll

File Type: DLL

  Section contains the following imports:

    perl510.dll
              10004064 Import Address Table
              10004690 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                  355 Perl_newXS_flags
                  21A Perl_croak
                  4AB Perl_vstringify
                  4A1 Perl_vcmp
                  1C0 Perl_Iunitcheckav_ptr
                  35A Perl_new_version
                  262 Perl_get_sv
                  254 Perl_form
                  18C Perl_Iscopestack_ix_ptr
                  20F Perl_call_list
                  1B2 Perl_Isv_yes_ptr
                  3F6 Perl_sv_2nv
                  21B Perl_croak_nocontext
                  4B0 Perl_warn_nocontext
                  19C Perl_Istack_max_ptr
                  3EC Perl_stack_grow
                  346 Perl_newSViv
                  19D Perl_Istack_sp_ptr
                  144 Perl_Imarkstack_ptr_ptr
                  19B Perl_Istack_base_ptr
                  21C Perl_croak_xs_usage
                  3F8 Perl_sv_2pv_flags
                  3F4 Perl_sv_2iv_flags
                  2B5 Perl_init_tm
                  3A8 Perl_safesysmalloc
                  3A9 Perl_safesysrealloc
                  348 Perl_newSVpv
                  3F5 Perl_sv_2mortal
                  3A7 Perl_safesysfree
                  25A Perl_get_context
                   9A Perl_Gcurinterp_ptr
                  417 Perl_sv_derived_from
                  507 win32_getenv

    MSVCR70.dll
              10004008 Import Address Table
              10004634 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                   F5 _except_handler3
                   6E __dllonexit
                   BE _adjust_fdiv
                  142 _initterm
                  204 _strnicmp
                  218 _tzset
                  1CA _putenv
                  2DD localtime
                  2BE gmtime
                  2E9 memset
                  30D strftime
                  2C9 isspace
                  2C3 isdigit
                  2CA isupper
                  311 strncpy
                  2BA getenv
                  308 strcmp
                  30E strlen
                  2E1 malloc
                  302 sprintf
                  2AE free
                  1BB _onexit

    KERNEL32.dll
              10004000 Import Address Table
              1000462C Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                   80 DisableThreadLibraryCalls

  Summary

        1000 .data
        1000 .rdata
        1000 .reloc
        3000 .text
[download]

I've implemented a fix, and having people test it now, just by 
implementing my own version of localtime and gmtime in the module (stu
+pid 
I know, but it works).
[download]

[reply]
[d/l]
[select]

localtime and gmtime are still being imported from msvcr70.dll. Is that what's stuffing things up ?

No. That's what cured the problem with tzoffset(). It means that all the CRT calls used by Time::Piece are now imported from the same version of the CRT, and therefore operate upon the CRT copy of the environment. Previously, those two were being imported from msvcrt.dll, and hence referenced its copy of the environment, while the tzset(), getenv() & putenv() were coming from msvcr70.dll and operating upon its copy.

The failure you're seeing now, is with strftime() & "%Z", which fails to return the timezone name. Which is weird because dumpbin shows strftime() being imported from the right place.

If the module was picking up anything from the wrong runtime, I'd have expected to see it also importing something from mscvrt.dll, but that's not the case.

[reply]