On Wed, Mar 5, 2014 at 3:05 PM, Corinna Vinschen wrote: > On Mar 5 06:52, Eric Blake wrote: >> On 03/05/2014 03:45 AM, Irfan Adilovic wrote: >> > If it is recognized that the executable was compiled against a >> > different sized struct tm, how would you instruct cygwin1.dll code not >> > to write to tm_gmtoff? >> >> Linker magic, the same as how we converted to 64-bit stat, and the same >> as what we will eventually have to do if we want to convert to 64-bit >> time_t. Basically, we add a new entry point, and alias the public name >> to the new entry point. Any old program is still linked to the old >> name, where we know they use the smaller size. Any new program is >> linked to the new name, where we know they use the larger size. New >> programs cannot run against the old dll, but the new dll is able to >> handle both old and new apps by virtue of dual entry points. > > Not in this case. I just applied a patch which simply tests the API > version of the executable and skips the code handling tm_offset and > tm_zone, which are just a few lines anyway.
Can you point me to the patch in CVS? I'd like to see the code -- being curious, as I already said. -- Irfan > What you describe above is what we would have to do if we change > sizeof(time_t) from 4 to 8 on 32 bit, which is something I won't have on > my plate any time soon. I'm quite satisfied that the 64 bit version has > a 8 byte time_t. Not that I wouldn't appreciate patches... > > > Corinna > > > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
