On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote:
> to understand the impact that a change to the size of
> time_t will have on a library's ABI, it must be possible to compile the
> headers that expose that API
Would the results of this analysis also be suitable for telling
interested maintainers whether it's safe to opt-in a library to LFS
and/or 64-bit time_t on i386, so that it will use 64-bit-time_t-safe
glibc functions internally?
(For example libdbus is already opted-in to LFS, and I'm reasonably
sure it doesn't break public ABI under 64-bit time_t either, because it
has a policy of avoiding most inclusions of system headers in its own
public API)
> The Ubuntu Foundations team have been putting in effort over the past two
> months, package-by-package, to figure out how to make them compile so that
> we know if their ABI is affected.
Is there a reasonably simple way that interested developers can try this
process for a package that they maintain?
I realise your analysis has been done on armhf, but i386 would probably be
an easier (and faster!) 32-bit architecture to deal with for many
developers, even though we don't intend to do the 64-bit time_t transition
systematically on i386.
> The "good" news is that, although there are over 1500 -dev packages yet to
> be analyzed, we have prioritized libraries based on the number of
> reverse-dependencies
Is the list you attached already in descending order by number of rdeps?
> libsdl1.2-compat-dev
The source package src:sdl12-compat recently took over libsdl1.2-dev
and libsdl1.2debian from the older src:libsdl1.2, which gives it quite
a lot of rdeps (I know because I did a mass bug filing for them!),
so having an answer for that one might reduce the rebuilds better than
you might think. I suspect it actually won't have time_t in its ABI,
although I could be wrong.
smcv
