So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?
The problem with doing this is that
1. A reverse dependency may depend on more than one library that uses time_t
in it's API. Said reverse dependency would not be able to be sanely
On Fri, Feb 09, 2024 at 05:36:53PM +0100, Ansgar wrote:
> Hi,
>
> On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote:
> > when introducing a new soname (no just a new package name), then one
> > should move to time64 even on i386 ?
>
> If you know all consumers of the package will be using
Hi,
On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote:
> when introducing a new soname (no just a new package name), then one
> should move to time64 even on i386 ?
If you know all consumers of the package will be using appropriate
compiler flags to get 64-bit time_t, then this is fine.
On Fri, 09 Feb 2024 at 15:24:50 +, Bill Allombert wrote:
> But fundamentally, how do we know how third-party binaries
> are compiled ?
We don't, but we can make some inferences.
If they are i386 binaries that already worked on Debian 12 or older,
and they call into time_t-sensitive ABIs (for
Le Fri, Feb 09, 2024 at 10:20:40AM +, Simon McVittie a écrit :
> On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> > if the maintainer
> > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> > it should enable it also on i386 (changed behavior).
> >
> > The
On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> if the maintainer
> has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> it should enable it also on i386 (changed behavior).
>
> The reason is that this does not now break ABI for any package (in Debian
> or out of
6 matches
Mail list logo
