Sparse doesn't work for me when compiling userspace code. Others have
experienced the same, so I refer to someone else's description of the
symptom:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505177
On my system, sparse tries several headers in order, neither of which
exists:
open("/usr/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/include/stddef.h", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h", O_RDONLY) = -1
ENOENT (No such file or directory)
Not a big surprise when looking at the headers that do exist:
Galway:/usr/lib/gcc/i486-linux-gnu# ll
total 20
drwxr-xr-x 4 root root 4096 2008-07-01 08:42 3.4.6
drwxr-xr-x 4 root root 4096 2007-09-23 17:59 4.0.4
drwxr-xr-x 3 root root 4096 2008-06-26 00:20 4.1
lrwxrwxrwx 1 root root 3 2007-09-23 20:57 4.1.3 -> 4.1
drwxr-xr-x 3 root root 4096 2008-07-13 11:06 4.2
lrwxrwxrwx 1 root root 3 2008-07-01 08:42 4.2.4 -> 4.2
drwxr-xr-x 4 root root 4096 2008-09-30 16:27 4.3
lrwxrwxrwx 1 root root 3 2008-07-01 08:42 4.3.1 -> 4.3
lrwxrwxrwx 1 root root 3 2008-08-08 18:18 4.3.2 -> 4.3
So why does sparse try 4.1.2 and not 4.1.3 or 4.3.2 or any other
variant?
[EMAIL PROTECTED]:/usr/src/kernel/sparse$ cat pre-process.h
#define GCC_INTERNAL_INCLUDE "/usr/lib/gcc/i486-linux-gnu/4.1.2/include"
Ah, it is hard-coding the path.
So what is the right solution to this problem? Call "gcc --version" and
parse the (deliberately hard) output? Or make a copy of the gcc headers
and ship them as /usr/lib/sparse/0.4.1/...?
Jörn
--
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]