Steve McIntyre writes: > wzss...@gmail.com wrote: >>Is there the option C? >> >>Draft: >> 1. define time64_t >> 2. for data_struct which act as a part of ABI, define a new data_struct64 >> 3. for function which act as part of ABI, define a new version func64. >> 4. patch all packages to use time64_t instead of time_t step by step. >> 5. set a time as deadline (2030?), and then treat all packages >>haven't finished >> the migration as rc-buggy. >> >> Since we have enough time, we can patch all packages in that period. > > It's possible, but... > > The problem here is that we have many thousands of packages to work > on, glibc up through other libs to all the applications that use > them. It's invasive work, and likely to take a very long time. Since > it's work that would *not* be needed for 64-bit architectures, we're > also likely to see push-back from some upstreams. > > 2030 is also too late to fix the problem - people are already starting > to see issues in some applications. We want to make a difference soon: > the earlier that we have fixes available, the fewer broken systems > will have to be fixed / removed / replaced later.
For arm* and mips*, we mostly seem to be talking about special-purpose systems where just switching to a new architecture/port doesn't seem to be that much as a problem as for i386. I think rebuilding the world and breaking ABI might thus be acceptable there. i386 seems different. I think option C above would be the only realistic proposal so far to fix the time_t problem for (parts of) i386, but if glibc upstream doesn't want to expose two interfaces then i386 will probably just break. Ansgar
