cygipc (and PostgreSQL) XP problem resolved!

[Charles Wilson]

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/