Unresolved external symbols in parsetm.c on WinCE

RESOLVED FIXED in 4.8

Status

defect
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: hiro, Assigned: hiro)

Tracking

({mobile})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

10 years ago
parsetm.c
/c/cygwin/home/user/hg/mozilla-central/objdir-wm6-test/xulrunner/dist/sdk/bin/ar
m-wince-link  -NOLOGO -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO -PDB:parsetm.pdb /c/c
ygwin/home/user/hg/mozilla-central/objdir-wm6-test/xulrunner/dist/lib/plc4.lib /
c/cygwin/home/user/hg/mozilla-central/objdir-wm6-test/xulrunner/dist/lib/nspr4.l
ib ws2.lib coredll.lib -DLL -OUT:parsetm.dll parsetm.obj
   Creating library parsetm.lib and object parsetm.exp
parsetm.obj : error LNK2019: unresolved external symbol _tzset referenced in fun
ction nspr_test_runme
parsetm.obj : error LNK2019: unresolved external symbol _putenv_s referenced in
function nspr_test_runme
parsetm.dll : fatal error LNK1120: 2 unresolved externals
make: *** [parsetm.dll] Error 96
Assignee

Comment 1

10 years ago
I commented out _putenv_s and _tzset and run this test anyway but I got strange result:

BEGIN TEST parsetm

rv = 0
Fri Mar 8 20:13:52 UTC 1912
rv = 0
Fri Mar 8 20:13:52 UTC 1912
    parsetm     Passed

END TEST parsetm

Is this another issue?
Assignee

Comment 2

10 years ago
(In reply to comment #1)

> BEGIN TEST parsetm
> 
> rv = 0
> Fri Mar 8 20:13:52 UTC 1912
> rv = 0
> Fri Mar 8 20:13:52 UTC 1912
>     parsetm     Passed
> 
> END TEST parsetm
> 
> Is this another issue?

This was year 2038 problem.

Comment 3

10 years ago
PRTime is a 64-bit timestamp, so it is not affected by the
year 2038 problem, and it should take care when using 32-bit
time_t to avoid the year 2038 problem.

So the strange output you showed in comment 1 should be an
NSPR bug.

To fix the build error, you can change
    #if _MSC_VER >= 1400
to
    #if _MSC_VER >= 1400 && !defined(WINCE)
Assignee

Comment 4

10 years ago
(In reply to comment #3)
> PRTime is a 64-bit timestamp, so it is not affected by the
> year 2038 problem, and it should take care when using 32-bit
> time_t to avoid the year 2038 problem.

I know. But I suspect this invoking mktime causes the problem.
http://mxr.mozilla.org/nspr/source/nsprpub/pr/src/misc/prtime.c#1632

> So the strange output you showed in comment 1 should be an
> NSPR bug.

OK. I will file a new bug entry.

> To fix the build error, you can change
>     #if _MSC_VER >= 1400
> to
>     #if _MSC_VER >= 1400 && !defined(WINCE)

I've already changed so.
Assignee

Comment 5

10 years ago
Posted patch A patchSplinter Review
I post the diff anyway.
Assignee: wtc → ikezoe
Status: NEW → ASSIGNED
Attachment #376791 - Flags: review?(wtc)

Comment 6

10 years ago
Comment on attachment 376791 [details] [diff] [review]
A patch

But we have code that is supposed to handle the case when
mktime() returns (time_t) -1:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/misc/prtime.c&rev=3.42&mark=1632,1634,1645-1652#1632

Could you find out why the code is not working?

I checked in your patch on the NSPR trunk (NSPR 4.8).

Checking in parsetm.c;
/cvsroot/mozilla/nsprpub/pr/tests/parsetm.c,v  <--  parsetm.c
new revision: 1.2; previous revision: 1.1
done

Updated

10 years ago
Attachment #376791 - Flags: review?(wtc) → review+

Updated

10 years ago
Target Milestone: --- → 4.8
Assignee

Comment 7

10 years ago
(In reply to comment #6)
> (From update of attachment 376791 [details] [diff] [review])
> But we have code that is supposed to handle the case when
> mktime() returns (time_t) -1:

Unfortunately on WinCE, mktime does not return -1 in some cases.

Before invoking mktime(&localTime) localTime.tm_year is 139 (i.e. 2039), but after invoking the function, localTime.tm_year is 2 and returns value (secs) is -2117514496.
Assignee

Comment 8

10 years ago
I opened bug 492450.

Comment 9

10 years ago
Thanks.  Then we can mark this bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Version: other → 4.7.4
You need to log in before you can comment on or make changes to this bug.