On 12/10/2010 06:51 PM, Jay K wrote: > > > I guess what we really need > > is to redefine fsblkcnt_t to become a 64 bit type. Oh well, this > > requires another backward compatibility hack, just like back when we > > switched to 64 bit off_t (Cygwin 1.5). Let's do it at the same time as > > we change sigset_t and time_t to 64-bits(with knock-on effects to > > struct stat, among others). In other words,all good changes, but certainly > > something that will take a lot ofplanning to pull off in one go. > > > Can you fix the jmp_buf size then too maybe? > It is blown up by a factor of 4. > http://sourceware.org/ml/cygwin/2009-01/msg00863.html > > I realize it has less/no value to fixing. > But I'm not sure how changing the others won't require *everything* > (just about) to be recompiled anyway. Maybe you rename functions somehow?
It's a matter of linker magic. For example, when stat() was changed from 32-bit to 64-bit sizes, cygwin1.dll was set up with two entry points, stat() and stat64(), but the dll export table only has one entry point stat(). Old apps that were compiled when there was only a 32-bit entry point continue to call stat(), but now that the dll export table exposes only stat pointing to stat64(), all recompilations automatically pick up the new stat size. There's also some #defines required in the headers to allow compilation of cygwin itself to support both function calls, while only exposing the new sizes to newly compiled apps. When (if? since someone has to do it) fsblkcnt_t is resized, you won't be required to recompile, but you won't benefit from the fixed sizes unless you recompile. And coreutils (including df) would obviously be one of the first apps to recompile with the new sizes, as a good testcase that we got the resizing done correctly. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
