This is the mail archive of the cygwin@cygwin.com 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]

Re: cygipc (and PostgreSQL) XP problem resolved!


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]