> have glibc provide a mechanism for other libraries (likely more core/widely used libs) to support both ABIs simultaneously The linked article is wrong to imp

> have glibc provide a mechanism for other libraries (likely more core/widely used libs) to support both ABIs simultaneously The linked article is wrong to imply this isn't possible - and it really doesn't depend on "GLIBC provide a mechanism". All you have to do is: * Compile the library itself with traditional time_t (32-bit or 64-bit depending on platform), but convert and call time64 APIs internally. * Make a copy of every public structure that embeds a time_t (directly or indirectly), using time64_t (or whatever contains it) instead. * Make a copy of every function that takes any time-using type, to use the time64 types. * In the public headers, check if everything is compiled with 64-bit time_t, and if so make all the traditional types/functions aliases for the time64 versions. * Disable most of this on platforms that already used 64-bit time_t. Instead (for convenience of external callers) make all the time64 names aliases for the traditional names. It's just that this is a lot of work, and little benefit to any particular library. the GCC 5 std::string transition is probably a better story than LFS, in particular the compiler-supported `abi_tag` to help detect errors (but I think that's only for C++, ugh - language without room for automatic mangling suck). (minor note: using typedefs rather than struct tags for your API makes this easier)