On 2/15/19 9:13 PM, Luc Van Oostenryck wrote: > On Fri, Feb 15, 2019 at 11:14:27AM +0100, Uwe Kleine-König wrote: >> uname -m is unreliable as the host architecture might not match the >> target architecture. This can happen when cross compiling or (more >> common) if you are running a 32 bit userspace on a 64 bit kernel. The >> latter makes sparse fail to build on some machines of the Debian build >> farm as for example some armhf builder run on arm64 kernels. >> >> This patch is only lightly tested and also misses details for mips* and >> so marked as RFC. > > Hi, > > Thanks you for trying this. > > I think it would be better to discard everything after the first '-'. This will not be enough. Consider for example arm-linux-gnueabi vs. arm-linux-gnueabihf. (I think this is the only offender in the official debian architectures according to my list I created to author my patch.) > For example, one of the machine I use have 'gcc -dumpmachine' > returning 'ppc64le-redhat-linux' and none of the pattern you've > used will match any BSD. The uname-backoff will catch them but > it's easy to avoid it. easy but wrong :-) > Please note that (as far as I can think) if you're on a platform A > and cross-compile sparse for platform B and then use sparse (with o > without cgcc) on this platform B, then everything should be OK. > OTOH, I'm not sure I understand exactly what is done in this > reproducibility test here. This is not really a cross-compile situation. It's just that the second builder isn't a native armhf machine, but it runs an arm64 kernel and the build is done in an armhf chroot. Similar for i686: That's a i686 chroot on an amd64 machine. The background here is that the Debian people will probably rely on this kind of setup because on real armhf hardware you cannot properly build software like libreoffice (IIRC), and the only way out to keep armhf supported in the long run is to be able to build packages on arm64 which has a bigger address space. > I suppose it's something like: > on platform A, sparse is compiled natively then, still on platform A, > sparse is used (with cgcc) with a cross-compiler for platform B. > In this sort of situation, even if cgcc is made somehow > 'cross-platform aware', I'm pretty sure there will be many others > problems. I noticed the naming to be wrong at least. Actually you want target_arch_specs instead of host_arch_specs. Similar for host_os_specs vs. target_os_specs. But using gcc -dumpmachine should do the right thing here, so my patch goes in the right direction I think. Best regards Uwe
Attachment:
signature.asc
Description: OpenPGP digital signature
