Re: [lmi] PATCH: Building lmi with gcc 10 and C++20

[Greg Chicares]

On 2020-06-05 16:08, Vadim Zeitlin wrote:
> On Fri, 5 Jun 2020 15:39:34 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> Apparently gcc-10 has moved to 'unstable' just minutes ago,

[I meant 'testing', not 'unstable': bullseye, not sid.]

>  Indeed it has, but how have you noticed it so quickly? Do you monitor the
> corresponding page of packages.debian.org for changes?

No, I was just testing my suite of rebuild-the-lmi-universe scripts,
and a surprise occurred between two test runs this morning.

> GC> I suppose I'll find that you've already adapted lmi's own code to gcc-10,
> GC> but that we'll need to upgrade wx.
> 
>  I _think_ that the version of wx currently used by lmi might compile fine
> with it already. I had to fix a few things to compile wx with gcc 10 in
> C++20 mode, but these were really problems due to C++20 changes, not gcc 10
> ones.

I'm trying that now, and will report the results here.

> GC> I'm surprised to see that 'stable' now has gcc-8.3:
> GC> 
> GC>   https://packages.debian.org/buster/g++-mingw-w64
> GC> | Package: g++-mingw-w64 (8.3.0-6+21.3~deb10u1)
> GC> 
> GC> because I thought 'stable' only received security upgrades, and IIRC it
> GC> still had gcc-7 when 'buster' became 'stable'.
> 
>  I don't quite remember this, but looking at
> 
> https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/commits/buster
> 
> it doesn't seem like there were any recent changes in this branch. So
> perhaps it did have 8.3 from the beginning? I've realized I don't really
> know how to check for this, but Buster changelog (which I'm reading from
> http://ftp.fr.debian.org/debian/dists/buster/ChangeLog) doesn't mention
> anything about MinGW updates.

Here's some evidence, from two older 'buster' chroots:

$ ls -ld /mnt/sda1/srv/chroot/*
drwxr-xr-x 24 root root 4096 Apr 18  2018 /mnt/sda1/srv/chroot/clean-buster
drwxr-xr-x 24 root root 4096 Apr 14  2019 /mnt/sda1/srv/chroot/lmi-buster2

$ /mnt/sda1/srv/chroot/clean-buster/usr/bin/i686-w64-mingw32-gcc-win32 
-dumpversion                                                                    
                           
7.3-win32
$ cat /mnt/sda1/srv/chroot/clean-buster/etc/debian_version 
buster/sid

$ /mnt/sda1/srv/chroot/lmi-buster2/usr/bin/i686-w64-mingw32-gcc-win32 
-dumpversion 
8.3-win32
$ cat /mnt/sda1/srv/chroot/lmi-buster2/etc/debian_version 
10.0

So compiler version seven certainly was used two years ago in a chroot
that labelled itself as "buster/sid", which might mean that in creating
it I specified "unstable" or "testing" rather than "buster"; but version
eight was already in use a year ago in a debian-10 (= "buster") chroot.

Oh...but 'buster' used to be 'testing', and now it's 'stable'. My prior
expectation is met as long as the compiler hasn't been upgraded since
'buster' became 'stable'.

> GC> Anyway, we're still using gcc-8.3 in production, so perhaps we should
> GC> just create a 'stable' chroot for now, because testing a wx upgrade
> GC> for this month's release would be "a bridge too far".
> 
>  I really don't see gcc in stable being updated to 10... And I'm quite sure
> that gcc-8 package is not going to be _removed_ from stable, no matter what
> (well, never say never, especially in 2020, the year of all the surprises,
> but still, something really cataclysmic would need to happen for a package
> to be removed from stable, rather than being upgraded).
But that's exactly okay. Until quite recently, we were using
  'bullseye' chroot, gcc-8.3
but 'bullseye' has upgraded to 9.3 and now 10.0, and adopting these
rapid gcc upgrades would require testing. OTOH, if we downgrade to
  'buster' chroot, gcc-8.3
then we keep the same compiler, which is great for stability; we
also downgrade the whole userland, but that won't break anything.
(Going back from vim-8.2 to vim-8.1 may be the only difference that
I'll notice.)

I just wish they hadn't picked Toy Story names matching /^bu.*/
for successive debian releases. At least 'bookworm' only shares
one initial character with its predecessor, and one can hope that
it won't be followed by 'bo-peep'.