This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 06/03/2014 13:17, Irfan Adilovic wrote:
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.
http://cygwin.com/ml/cygwin-cvs/2014-q1/msg00092.html -- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |