Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3EBC8ED0.4040906@ece.gatech.edu> Date: Sat, 10 May 2003 01:32:00 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: gmane.os.cygwin To: Robert Collins CC: Jason Tishler , cygwin AT cygwin DOT com Subject: Re: cygipc (and PostgreSQL) XP problem resolved! References: <20030506174725 DOT GE1652 AT tishler DOT net> <3EB84F52 DOT 3020608 AT ece DOT gatech DOT edu> <20030507133326 DOT GA1824 AT tishler DOT net> <3EB9A54B DOT 8060500 AT ece DOT gatech DOT edu> <20030508135217 DOT GD512 AT tishler DOT net> <3EBB22F5 DOT 4000801 AT ece DOT gatech DOT edu> <1052541657 DOT 1675 DOT 5 DOT camel AT localhost> In-Reply-To: <1052541657.1675.5.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: >>Nope -- I'm an idiot. You and Igor are correct. But I'm more concerned >>about the other issues I raised, to which nobody has yet responded >>(although I'm still working thru the mail). To whit: 64 bit key_t and >>coordination with cygwin dll/newlib. > > > Well, theres the API break coming up with cygwin1.dll - do it in sync > with that, IMO. Ah, yes, the "maintainers better recompile, fast" API break. Now, I do NOT want to start a panic-fest and I realize this thread is on the main cygwin list. So, non-cygiwn-developer types, please ignore any possible misinformation below, and put away your panic button. Breathe deep, think of your happy place, and get your Hitchhiker's Guide that says "Don't Panic" in big friendly green letters... Okay, let me make sure I understand the upcoming changes: 1) Corinna added some 64 bit stuff. Yay, Corinna! 2) She also added compatibility macros of some sort, and carefully changed typedefs to hopefully 'Do The Right Thing' 3) existing applications will continue to run fine with no recompilation, if the new cygwin1.dll is dropped onto a working system, and those apps will get the previous, 32bit behavior. 4) recompiling new apps will in most cases mean that IF the app supports it, it will get 64bit behavior -- with one caveat. 5) The caveat: compiled objects can't learn about new typedefs without being recompiled. Applications that rely on shared libraries can therefore run into trouble: if you recompile the app -- but not the shared library -- then the app thinks "64bits" and the sharedlib thinks "32bits" == boom. That is, pngcrush.exe depends on cygpng12.dll -- but is distributed separately from it. So if you recompile pngcrush but not cygpng12.dll -- then you may have a problem. Conclusion: package maintainers that distribute shared libs need to recompile ASAP, so that dependent apps can be recompiled if needed. Caveat to the caveat: this analysis ONLY applies if the compiled object (DLL, static lib, executable, etc) actually USES one of the symbols whose typedef has changed. Currently, the list of affected packages is pretty small (zlib is one). Assuming the above is all correct, then I have some questions (and perhaps these should be addressed on cygwin-apps) 1) NOT counting key_t, what symbols do I need to grep for in my packages? _off32_t _off64_t acl32 aclcheck32 aclfrommode32 aclfrompbits32 aclfromtext32 aclsort32 acltomode32 acltopbits32 acltotext32 facl32 fgetpos64 fopen64 freopen64 fseeko64 fsetpos64 ftello64 _open64 _lseek64 _fstat64 _stat64 mknod32 And what else? 2) What *exactly* was the compatibility magic that Corinna did? Should similar magic be applied to key_t (assuming a transition to 64bit key_t is desirable at this point?) 3) What sort of timeline are we looking at for me to recompile zlib and have a new cygwin1.dll-compatible version ready to go; ditto cygipc (IF it is determined that adding cygipc to the dist is a good idea -- so far we've only heard from a few folks on this, counting cgf's rather diffident proposal) --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/