Mail Archives: cygwin/2003/05/10/01:34:08
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/
- Raw text -