On 15/02/2019 20:17, Uwe Kleine-König wrote: > On 2/15/19 6:22 PM, Ramsay Jones wrote: >> >> >> On 15/02/2019 08:34, Uwe Kleine-König wrote: >> [snip] >>> I use CC = gcc-8 for the debian package because other it can happen (and >>> it actually did) that /usr/bin/gcc was updated from gcc-X to gcc-(X+1) >>> and then sparse started to fail because it still used >>> /usr/lib/gcc/x86_64-linux-gnu/X/ (i.e. the output of >>> >>> gcc --print-file-name= >>> >>> ) which disappeard as it changes on major version bumps. >>> >>> So sparse depends explicitly on the current gcc version and uses this. >> >> Hmm, yes, sparse may well depend a little too much on gcc. ;-) >> >> Having said that, these values built-in to sparse are just >> default values that can be set from the command-line of >> sparse (see -gcc-base-dir and -multiarch-dir). Indeed they >> _are_ set by cgcc by running the 'specified c compiler' at >> each invocation, if not _also_ specified on the cgcc command >> line. >> >> Hmm, do you remember how/what failed? (I suppose this was not >> a kernel usage). > > Right. The problem was https://bugs.debian.org/906472 . Oh, my word! So, the 'horst' package was using sparse on user-space code directly, not via 'cgcc -no-compile'? I am somewhat surprised that it worked at all! ;-) Also, it seems that the package was built in a chroot environment where the compiler was 'swapped out' mid build! What ??? No, no I must have misunderstood something. :( I have never built a debian package, so you must excuse my ignorance of package build requirements. 'sparse' has improved quite a bit recently, but I would still highly recommend using 'cgcc [-no-compile]' on user-space code! ATB, Ramsay Jones