Am Montag, den 02.03.2020, 19:38 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld: > > > Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup: > > > > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going > > > > to be a thing rather soon. Assuming that things like the Python3 > > > > migration don't cause more of a standstill for 2.21.0 than we imagine, > > > > but then one can still decide to stop being disciplined until things are > > > > fixed enough to get 2.21.0 done. > > > > > > Understood. In that case I'll work to prepare GUB for 2.21.0, at least > > > something I can likely help with. > > > > See > > https://github.com/gperciva/gub/pull/71 > > . Incidentally this only > > works for mingw after #5799 is applied (or at least the first commit). > > So while it has the potential to break, it actually fixes things 😉 > > > > FTR: I guess the offending commit is b51e6224ab ("Issue 5776/1: Drop > > check for std::vector::data()") where I innocently removed an inclusion > > of config.hh. I'd argue that it has been broken before, this was only > > uncovered by removing the include. > > Frankly, I am not overly interested in arguing what level of brokenness > is really "somebody else's problem"™. Since you are the person who > currently appears to have the best overview, could you design a fix you > consider less broken?
Sure, the solution is to apply #5799. Turns out the solution is not only for x86_64-w64-mingw32 but also for 32 bit mingw that GUB uses. So I'm arguing that it should go in before 2.21.0 is cut. Jonas
signature.asc
Description: This is a digitally signed message part
