Win64 support, second take

Win64 support, second take

[Stefan Eilemann]

Keith, List,

I have seen your posting from March 2006 regarding Win64 support.
I am in the need of a Win64 port -- has anybody in the meantime
successfully build a libpthread on Win64, or is the code in more
or less the same state?


Cheers,

Stefan.
-- 
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann

Re: Win64 support, second take

[Ross Johnson]

Stefan Eilemann wrote:
> Keith, List,
>
> I have seen your posting from March 2006 regarding Win64 support.
> I am in the need of a Win64 port -- has anybody in the meantime
> successfully build a libpthread on Win64, or is the code in more
> or less the same state?
>
The current CVS head contains some additional changes for Win64 build
and test provided by Kip, who subsequently reported that he could now
build and complete all tests, although there were warnings:-

Kip wrote:-
"2. Since you are using /WX, the tests fail as soon as Visual Studio
outputs a warning, it currently outputs two different warnings, one is
related to _ftime64 being deprecated, which I can suppress by including
/D_CRT_SECURE_NO_DEPRECATE in the CFLAGS variable. The other is more
troublesome, there are about 20-30 places in the tests where you copy a
value of the _timeb structure into the timespec structure. The problem
with that is in 64-bit mode, most of the values of the _timeb structure
are 64-bit integers (ie. __time64_t) and the timespec structure only
holds 32-bit integers (ie. long) and Visual Studio issues a warning
about truncating the numbers during the assignment. Any suggestions on
what fix should be applied here?"

The _timeb issue has not been properly resolved, although I'm guessing
it is not a problem yet. AFAICS the structure elements still represent
the same time components with the same epoch as the 32 bit version, and
no actual truncation is taking place. I'm assuming that 2038 is still
the critical year for this. Please correct me if that understanding is
wrong.

Direct anonymous access to the pthreads-win32 CVS repository is
described on the project main page at:-
http://sourceware.org/pthreads-win32/

I plan to package the next version 2.9 of the library once I've reviewed
and included some more WinCE changes, but my day job is a little full-on
at the moment.

Regards.
Ross
>
> Cheers,
>
> Stefan.

RE: Win64 support, second take

[Streithorst, Kip]

Ross,

If you think the _timbe and timespec warning is ok, I would suggest
adding cast's to the 20-30 places so that we can re-enable /WX in the
Makefile.  That would at least make it obvious that the 2038 issue on
the copy across is intentional.

Thanks,
Kip

-----Original Message-----
From: pthreads-win32-owner@sourceware.org
[mailto:pthreads-win32-owner@sourceware.org] On Behalf Of Ross Johnson
Sent: Friday, January 26, 2007 8:45 PM
To: Pthreads-Win32 list
Subject: Re: Win64 support, second take

Stefan Eilemann wrote:
> Keith, List,
>
> I have seen your posting from March 2006 regarding Win64 support.
> I am in the need of a Win64 port -- has anybody in the meantime
> successfully build a libpthread on Win64, or is the code in more
> or less the same state?
>
The current CVS head contains some additional changes for Win64 build
and test provided by Kip, who subsequently reported that he could now
build and complete all tests, although there were warnings:-

Kip wrote:-
"2. Since you are using /WX, the tests fail as soon as Visual Studio
outputs a warning, it currently outputs two different warnings, one is
related to _ftime64 being deprecated, which I can suppress by including
/D_CRT_SECURE_NO_DEPRECATE in the CFLAGS variable. The other is more
troublesome, there are about 20-30 places in the tests where you copy a
value of the _timeb structure into the timespec structure. The problem
with that is in 64-bit mode, most of the values of the _timeb structure
are 64-bit integers (ie. __time64_t) and the timespec structure only
holds 32-bit integers (ie. long) and Visual Studio issues a warning
about truncating the numbers during the assignment. Any suggestions on
what fix should be applied here?"

The _timeb issue has not been properly resolved, although I'm guessing
it is not a problem yet. AFAICS the structure elements still represent
the same time components with the same epoch as the 32 bit version, and
no actual truncation is taking place. I'm assuming that 2038 is still
the critical year for this. Please correct me if that understanding is
wrong.

Direct anonymous access to the pthreads-win32 CVS repository is
described on the project main page at:-
http://sourceware.org/pthreads-win32/

I plan to package the next version 2.9 of the library once I've reviewed
and included some more WinCE changes, but my day job is a little full-on
at the moment.

Regards.
Ross
>
> Cheers,
>
> Stefan.


######################################################################
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.
######################################################################

Re: Win64 support, second take

[Stefan Eilemann]

On 27. Jan, 2007, at 2:45 , Ross Johnson wrote:

[...]
> Direct anonymous access to the pthreads-win32 CVS repository is
> described on the project main page at:-
> http://sourceware.org/pthreads-win32/
>
> I plan to package the next version 2.9 of the library once I've  
> reviewed
> and included some more WinCE changes, but my day job is a little  
> full-on
> at the moment.

Ross,

Thanks for the summary. It does indeed look good for the 64-Bit version.
I am planning to integrate it into my project in about a month - Any
chance that there will be official 64Bit libraries for the 2.9 release?
Otherwise I'll build them myself.


Cheers,

Stefan.
-- 
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann

Re: Win64 support, second take

[Romanchuk, Mike]

> "2. Since you are using /WX, the tests fail as soon as Visual Studio
> outputs a warning, it currently outputs two different warnings, one is
> related to _ftime64 being deprecated, which I can suppress by
including
> /D_CRT_SECURE_NO_DEPRECATE in the CFLAGS variable. The other is more
> troublesome, there are about 20-30 places in the tests where you copy
a
> value of the _timeb structure into the timespec structure. The problem
> with that is in 64-bit mode, most of the values of the _timeb
structure
> are 64-bit integers (ie. __time64_t) and the timespec structure only
> holds 32-bit integers (ie. long) and Visual Studio issues a warning
> about truncating the numbers during the assignment. Any suggestions on
> what fix should be applied here?"
>
> The _timeb issue has not been properly resolved, although I'm guessing
> it is not a problem yet. AFAICS the structure elements still represent
> the same time components with the same epoch as the 32 bit version,
and
> no actual truncation is taking place. I'm assuming that 2038 is still
> the critical year for this. Please correct me if that understanding is
> wrong.

I think the way to solve this is by fixing the timespec to use a time_t
for the tv_sec member.  As far as I can tell, this is the correct way to
specify the timespec structure.  This should also solve the problem
because Microsoft has already made time_t 64-bit compatible.  The
following is from the MSDN Library:

"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. This is not recommended because your application may
fail after January 18, 2038; the use of this macro is not allowed on
64-bit platforms."

Mike.