Project

General

Profile

Bug #2999

_WIN32 already has tzname and daylight defined.

Added by docwhat (Christian Höltje) over 9 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
ruby -v:
1.9.1-p376
[ruby-core:28906]

Description

=begin
I had to change line 129 from:
#if !defined(OS2) && defined(HAVE_TZNAME)
to:
#if !defined(OS2) && defined(HAVE_TZNAME) && !defined _WIN32

This is under Windows with Visual Studio 8 - 2005.

daylight and tzname are both already defined and the new extern's are not compatible with the previous definitions.
=end

History

#1

Updated by rogerdpack (Roger Pack) over 9 years ago

=begin
Is this the case with trunk as well?
=end

#2

Updated by nobu (Nobuyoshi Nakada) over 9 years ago

  • Status changed from Open to Feedback

=begin
I could build with no problem.
What's the exact error messages and the compiling command?
=end

#3

Updated by nobu (Nobuyoshi Nakada) over 9 years ago

  • Status changed from Feedback to Open
  • Priority changed from 5 to 3

=begin
This ticket closes at the end of April 2010, if no feedback comes till then.

=end

#4

Updated by nobu (Nobuyoshi Nakada) over 9 years ago

  • Status changed from Open to Rejected

=begin
No response, No problem.
=end

#5

Updated by docwhat (Christian Höltje) over 9 years ago

=begin
re: No response, No problem.

Redmine isn't sending me emails, so I didn't know I should respond. I just changed my email address to see if that fixes it. If I don't respond, you can contact me directly at http://docwhat.org/email and I'll complain to the redmine admins.

re: error message and compiling command?
Example Cl.EXE invokation...

cl.exe -nologo -I. -I../../.ext/include/x64-mswin64_80 -I../../../ruby-1.9.1-p378/include -I../../../ruby-1.9.1-p378/ext/dl
-nologo -MD -O2b2xty- /O2 -DRUBY_EXTCONF_H=\"extconf.h\" -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -Focallback-2.obj
-c -Tccallback-2.c
=end

#6

Updated by docwhat (Christian Höltje) over 9 years ago

=begin
Ignore the error message and compiling command part. That was meant for bug #3006.
=end

#7

Updated by docwhat (Christian Höltje) over 9 years ago

=begin
Okay, it looks like this isn't an issue anymore.

I'm guessing that either:
a) p378 fixed it.
b) I wasn't compiling with vcvars.bat before (which would have been stupid, but it's not like it's obvious when you forget).

=end

Also available in: Atom PDF