On Fri, 2024-02-09 at 22:01 +0100, Bill Allombert wrote:
> On Fri, Feb 09, 2024 at 09:16:00PM +0100, Ansgar wrote:
> > with the upcoming time_t & friends 64-bit transition, dpkg-
> > buildflags
> > will be used to configure the ABI in use.
>
> This decision comes from the wrong premise that the use of dpkg-
> buildflags
> is universal, which is not the case. Hence it needs to be
> reconsidered.
> There is not magic that will make all packages use dpkg-buildflags
> consistently
> in the timeframe of this migration.
If packages do not use dpkg-buildflags, but use any ABI changed by the
transititon, they will just be broken and must already be fixed.
> > Thus all compiler
> > invocations *must* use the flags specified by dpkg-buildflags to
> > avoid
> > ABI inconsistencies like this one:
> >
> > struct T { time_t a; time_t b; };
> >
> > If this struct is accessed from both `libfoo1t64` (built respecting
> > dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a
> > user
> > invoking gcc themselves), the result is probably not what one
> > wants.
> >
> > Thus `dpkg-buildflags` *must* be used by all packages *and* all
> > users,
> > including users building their own software. There is one
> > exception
> > when libraries provide both 32-bit and 64-bit time_t ABIs like
> > glibc
> > itself (but I doubt there are many of those).
>
> No, it is required that packages use correctly the right compiler
> flags.
The interface for the compiler flags is dpkg-buildflags. See
the transition annoucnement.
I did not come up with this interface, but am not aware of an
alternative.
(C++ ABI changes were handled differently, but this transition did
choose a different way; I'm not aware of the details why.)
> Since packages need to be reuploaded anyway this is not a real issue.
> dpkg-buildflags is not required for that, and does not necessarily
> achieve it
> either, since upstream build system might not honor the environment
> variables
> CFLAGS etc. consistently.
Packages must ensure that these flags are passed correctly to the
upstream build system. As mentioned above, any package not doing so is
already broken (or will be by the transition).
> > Any compiler invocation missing these *should* be a serious bug.
> > (This should probably be mentioned in user documentation as well.)
>
> This a different issue than mandating dpkg-buildflags.
You can also establish another interface, but currently the only one
I'm aware of is dpkg-buildflags.
Ansgar
