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
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.
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. ######################################################################
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
> "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.