Hi, thanks for the patch. It looks a bit strong though, undefining stuff like that unconditionally. Do you have pointers to the Ubuntu bug or something? I've looked at upstream commits and issues and couldn't see anything there.
My understanding of the issue. In glibc _FILE_OFFSET_BITS=64 is used to substitute the standard file handling types and functions with versions that use 64-bit file offsets. Similarly _TIME_BITS=64 is used to susbstitute time handling types and functions with versions that use 64-bit seconds counts. All of this only applies to 32-bit architectures, on 64-bit architectures the default types in glibc are 64-bit. The "time64" transition was implemented by defining _TIME_BITS=64 and _FILE_OFFSET_BITS=64 by default in both dpkg-buildflags and the compiler. That's fine for normal code, but tests/src/libsystem.c is not normal code, it's a file of "test mocks" that override functions in glibc for testing purposes. If _FILE_OFFSET_BITS=64 is defined, it ends up trying to override "open64" twice, rather than trying to override both "open" and "open64" If we undef _FILE_OFFSET_BITS then we must also undef _TIME_BITS, otherwise the glibc headers will refuse to compile. So the patch seems reasonable to me, and since this is only test code, it appears to be pretty low risk. We would appreciate having this fix in unstable so the time_t transition can move forward.
