On Mon, Aug 20, 2018 at 04:51:30PM +0300, Adrian Bunk wrote: > On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote: > > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote: > > > How should we handle architecture-specific patches properly inside > > > Debian? > > > > Why should there ever be architecture-specific patches? > > > > I get that there sometimes need to be vendor-specific patches, because > > defaults may differ between distributions. But why on earth should > > defaults differ between architectures? That just makes no sense. Things > > like uintXX_t and htonl() should take away most architecture-specific > > differences, and then all that remains are things like ensuring > > alignment is done right. You don't need patches for that; you need > > bugfree code for that. > >... > > Are we discussing bugfree code or are we discussing reality? > > As an example, the non-release architectures of Debian are either > brand-new (riscv64) or fringe with usually brittle upstream status > in the toolchain (the other 13 non-release architectures). > > Now look at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 > > "Keywords: deferred" means "This bug was deemed too risky to attempt to > fix during stabilization stages. Deferred to a development stage of a > subsequent release." AKA "Target Milestone: 9.0" > > The bug seems to be rare enough on x86 to warrant that. > > On ia64 this bug breaks most code that builds with -O3, > Qt and Pyhon 3.7 were among the first FTBFS. > > The fix will likely be in generic code in gcc.
Yes, but there's a huge difference here. Compiling code for a given platform is not the same thing as running on said platform. If the compiler runs correctly, then it doesn't matter which platform it runs on; it's still the same compiler. The architecture-specific issues that I was talking about, when they occur in a compiler for a platform, can be patched perfectly safe, with or without the agreement from upstream. If you see that a compiler misbehaves when compiling *on* platform X but not when compiling *on* platform Y (but in both cases compiling *for* platform Z), then you need to fix the code on all platforms -- the ones where it is broken as well as the ones where it is not broken -- and ship the fixed code. Hopefully to upstream too, but definitely to Debian. The architecture-specific code in a compiler that occurs when compiling for a given platform needs to be built into *any* compiler which produces code for that platform; so, not just in src:gcc-X, but also in src:gcc-X-cross and src:gcc-X-cross-ports. So even if we were to add code to dpkg-source to support architecture-specific patches (which we don't currently and which I think we definitely shouldn't), then this still wouldn't help the GCC packages in Debian. [...] > And this can happen even on release architectures in a release. > In src:gcc-6 the fix for #727621 [2], which is required for > building LLVM on armel, is applied only on armel in stretch. No; it is applied only on compilers that produce armel *output* in stretch. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab