Hi,

On 2022-11-09 22:24, Paul Gevers wrote:
> Control: affects -1 utox
> 
> Hi Aurelien, Christian,
> 
> On 09-11-2022 21:25, Aurelien Jarno wrote:
> > It happens that emalloc is provided by libcheck_pic.a (from the check
> > package) and that ASAN trips when linked objects are built with
> > different GCC versions. In that case both glibc and check needs to be
> > built with the same GCC version. The switch of glibc from GCC 11 to GCC
> > 12 triggered the issue.
> 
> Thanks for your, as always, splendid debugging work.
> 
> > I am not sure why it happens on s390x only
> > though.
> > 
> > It appears that the easiest way to fix the problem is to binNMU check:
> > 
> >    wb nmu check . ANY . -m 'Rebuild against GCC 12 (Closes: #1023531).'
> > 
> > I'll add a breaks on the glibc side once done.
> 
> How can we prevent this from slipping into testing in the future? It's not
> really great that glibc and check need to be in lockstep and we have no
> triggers in place to detect that. (I mean, relying on the utox test feels,
> ... sub-optimal). The opposite could happen as well, that check is build
> with the next gcc while glibc is with an older version.

Unfortunately I am not sure we want to do that, as we don't know if this
GCC version incompatibility (that seems specific to s390x, at least in
the utox context) will also happen for the next GCC version.

Now if we consider it will break again, the more elegant solution would
be to change check to use dynamic linking instead of static linking.
Alternatively we can export the GCC version used to compile GLIBC (for
instance providing libc6-gcc11 or libc6-gcc12) and add some code in
check to add a depends on that. A simpler way would just be to add a
depends on the major glibc version (so libc6 (>> 2.36), libc6 (<< 2.37))
as we *tend* to change the GCC version used at the same time than the
major version (at least for sid, not true for experimental).

Regard
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature

Reply via email to