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. But, in the case we don't do a bump, why not update the tuple? This'd allow easy communication of whether we have 32 bit time to all components of the system, and, in lieu of a better detection mechanism, it'd allow anyone at a glance to look at a hosts tuple and see whether it is compatible with something based on the tuple it was built on. AFAIK the only reason not to do that is cosmetic - and it is ugly, but this is for a dead platform, so I'm not too worried. > Rationale: > > * We want that a user of a distro with the new ABI can build > packages in the usual way: > - ./configure; make; make install (when using Autoconf), or > - make; make install (when there is just a Makefile). > This *requires* that gcc and clang get patched, as indicated > above. > (Only changing Debian-specific files or variables won't do it.) > > * Once this has been done, is there a need for a triplet change? > Not in the toolchain, and not in the packages either. > Needs that have been mentioned in [1][2]: > > - Users would like to know in which ABI they / their distro lives. > This can be done through a property in /etc/os-release. > > - "risks incompatibility with other distributions" [2] > What is the problem? Do we expect users to build binaries > on 32-bit distro X and try to run them on 32-bit distro Y? > Or do we expect binary package distributors (like Mozilla, > videolan.org) to do so? > It was my impression that this approach is doomed anyway, > because so many shared libraries have different major version > in distro X than in distro Y. It is, many do it anyway, and what's worse, many users misguidedly prefer it to better approaches (like the ones you mentioned). > And that such binary package distributors use flatpak, AppImage, etc. > precisely to get out of this dilemma. > > - Building gcc and glibc might need some particular options. > Such options can be documented without requiring a new triplet. > > References: > [1] https://wiki.debian.org/ReleaseGoals/64bit-time > [2] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration -- Arsen Arsenović
signature.asc
Description: PGP signature
