Hi Guillem, On Thu, Aug 31, 2023 at 02:12:51AM +0200, Guillem Jover wrote: > So this happened, and Johannes reported that this seems to be breaking > cross-building. :( > > The problem, which is in fact not new, but is made way more evident > now, is that the flags used are accepted only per arch, so when > passing for example CFLAGS (the host ones) into CC_FOR_BUILD, then > that one will not know about them and fail. (We have had this problem > up to now as we set flags per arch as some are broken in some arches, > but it being a problem depends on the host and build arches involved.)
I agree that the problem is not new. In general, stuff we compile with the build architecture compiler is not installed into any .deb. We only build such things for running them during build. Most flags do not influence the behaviour of the resulting executables. tim64 may be a notable exception here. So for a lot of cases, you can just pretend that for build tools you don't need any Debian-specified compiler flags. All you need to do here is deleting the flags when invoking build tools. I've hit such cases in the past and done just that. > I'm thinking about uploading later today a workaround to disable these > flags for now when cross-building. And then for the next release after > that support for <flags>_FOR_BUILD which can then take into account > these arch differences. I think some upstream code can already make > use of these, but this might need going over packaging or upstream > build systems to adapt/fix stuff. :/ I'd rather not. These have always been bugs and some of them have patches or have been uploaded. I don't expect them to be that many. It's rather few packages that use the build architecture compiler at all. Of those, a portion manages to keep host flags out. Let's just fix the others. In case you really want to pass the correct flags, you may use CFLAGS_FOR_BUILD=$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CFLAGS) Guillem pointed out that these are still affected by DEB_<flags>_MAINT_<op> and DEB_<flags>_<op>, so we should eventually rely on dpkg providing more support here, but I don't see the lack of such support as a blocker here. > And until that's done I don't think the workaround can be lifted, > and cross-compiling will generate different binaries than > non-cross-compiling. Another option would be to revert this change > until we can add it safely, but that would also be unfortunate. > OTOH, upstream code that uses stuff like CFLAGS with things like > CC_FOR_BUILD are already broken in regards cross-building, so perhaps > this can be an opportunity to flush them out? Such cross vs native differences are very bad from my point of view, because we have very little tools to detect them. It's an area where we lack QA. Let's not make that worse. In the grand scheme of things breaking cross builds, I think this is a drop in the bucket. Helmut
