* Arsen Arsenović via Gcc: > Bruno Haible <br...@clisp.org> writes: > >> Paul Eggert wrote: >>> I'd rather just switch, as Debian has. >> >> I'd go one step further, and not only >> make the ABI transition without changing the canonical triplet, >> but also >> make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 >> among their predefines. > > At that point, we should bump SONAME of libc and simply remove 32-bit > time support. This would probably be okay generally. Just doing the > predefine doesn't really fix anything - all the problems of not being > able to detect whether t64 support exists still persist, with no > mechanism to prevent mixing.
Defaulting to 64-bit time_t would also make dlsym etc. work again. For post-GLIBC_2.1 targets (where valid binaries are expected to use symbol versioning) it's not absolutely required to do a soname bump, just changing the symbol version baseline should be enough (set DEFAULT to e.g. GLIBC_2.40 in shlib-versions). Old binaries will use __libc_start_main@GLIBC_2.4 or __libc_start_main@GLIBC_2.34, and fail to load. This could be a more source-compatible change becaue I suspect not everyone uses LIBC_SO in <gnu/lib-names.h> to get the soname for libc.so. I do not have a strong opinion whether this should be done for most 32-bit targets. Except for i386, where I think we should aim to preserve compatibility with legacy binaries for many years to come. All these changes have implications for LSB complinace, as people keep reminding us: LoongArch glibc does not provide libutil shared object, against LSB 5.0 <https://sourceware.org/bugzilla/show_bug.cgi?id=31136> But as I explained on the ticket, the way LSB is constructed, it's surprisingly architecture-specific even in its generic parts, and 32-bit Arm with its GLIBC_2.4 baseline won't have the required GLIBC_2.3.4 symbols (such as __chk_fail@GLIBC_2.3.4) anyway. Thanks, Florian
