Hard-coded gcc header path

Hard-coded gcc header path

[Jörn Engel]

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?
joern@Galway:/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 from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hard-coded gcc header path

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Tue, 2008-11-11 at 14:58 +0100, Jörn Engel wrote:

> So why does sparse try 4.1.2 and not 4.1.3 or 4.3.2 or any other
> variant?
> joern@Galway:/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.

Well, sort of. The patch is actually determined at sparse build time, so
right now sparse requires you to build it against the same compiler that
you are currently using. If you rebuild sparse with your shiny new
compiler you'll notice that it'll end up with a different path in
pre-process.h.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Hard-coded gcc header path

[Jörn Engel]

On Tue, 11 November 2008 15:01:46 +0100, Johannes Berg wrote:
> 
> Well, sort of. The patch is actually determined at sparse build time, so
> right now sparse requires you to build it against the same compiler that
> you are currently using. If you rebuild sparse with your shiny new
> compiler you'll notice that it'll end up with a different path in
> pre-process.h.

Then the short-term solution for debian is clear.  Simply rebuild the
package and add a dependency on a specific gcc version.

Jörn

-- 
Fantasy is more important than knowledge. Knowledge is limited,
while fantasy embraces the whole world.
-- Albert Einstein
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hard-coded gcc header path

[Bernd Petrovitsch]

On Tue, 2008-11-11 at 14:58 +0100, Jörn Engel wrote:
[...]
> 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

There is `gcc -dumpversion`. But it doesn't help if your compiler is
from e.g. /opt/gcc-4.1.2 (where mine usually are).
And `which`, `type -all`, and similar also doesn't really help as the
reported pathname can be actually the ccache binary ....

So you want to use the output of
----  snip  ----
gcc -v -E - </dev/null 2>&1 >/dev/null | sed -n -e '/^#include <\.\.\.> search starts here:/,/^End of search list\./s/^ \(.*\)/\1/p'
----  snip  ----
which also seems to work with non-standard paths (like /opt) and ccache
in between.

	Bernd

PS: The core of the above line is from
    http://sourceware.org/ml/crossgcc/2006-12/msg00038.html. The quite
    trivial `sed` filter is by me.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug#505177: Hard-coded gcc header path

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Tue, Nov 11, 2008 at 02:15:29PM +0000, Jörn Engel wrote:
> On Tue, 11 November 2008 15:01:46 +0100, Johannes Berg wrote:
> > 
> > Well, sort of. The patch is actually determined at sparse build time, so
> > right now sparse requires you to build it against the same compiler that
> > you are currently using. If you rebuild sparse with your shiny new
> > compiler you'll notice that it'll end up with a different path in
> > pre-process.h.
> 
> Then the short-term solution for debian is clear.  Simply rebuild the
> package and add a dependency on a specific gcc version.

Which sucks badly because the default gcc is not always the same on
every arch, and more importantly, people may want to use different GCCs.
It would look like a better idea to ask gcc for its include path
properly.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Hard-coded gcc header path

[Jörn Engel]

On Tue, 11 November 2008 21:13:28 +0100, Pierre Habouzit wrote:
> On Tue, Nov 11, 2008 at 02:15:29PM +0000, Jörn Engel wrote:
> > 
> > Then the short-term solution for debian is clear.  Simply rebuild the
> > package and add a dependency on a specific gcc version.
> 
> Which sucks badly because the default gcc is not always the same on
> every arch, and more importantly, people may want to use different GCCs.
> It would look like a better idea to ask gcc for its include path
> properly.

Maybe not even that.  It is conceivable to want sparse on systems that
don't even have gcc installed.  The BSDs seem to favor pcc lately.  So
the preferred long-term solution would be for sparse to ship its own
headers.

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hard-coded gcc header path

[Morten Welinder]

The problem is not the header files, but that we need to ensure that the
proper include path is set up.

This is needed because sparse currently tries to mimic some
indeterminate gcc version in terms of predefines.  A similar solution
would be needed to mimic any other compiler.  We obviously need
a default path for system headers somehow.

In this case, we could probably get away with accepting a definition
of GCC_INTERNAL_INCLUDE on the command line and use that in
preference over whatever is in pre-process.h

Morten

Re: Hard-coded gcc header path

[Jörn Engel]

On Tue, 11 November 2008 16:00:21 -0500, Morten Welinder wrote:
> 
> The problem is not the header files, but that we need to ensure that the
> proper include path is set up.
> 
> This is needed because sparse currently tries to mimic some
> indeterminate gcc version in terms of predefines.  A similar solution
> would be needed to mimic any other compiler.  We obviously need
> a default path for system headers somehow.
> 
> In this case, we could probably get away with accepting a definition
> of GCC_INTERNAL_INCLUDE on the command line and use that in
> preference over whatever is in pre-process.h

That doesn't strike me as an improvement.  I have a workaround, which is
to create a symlink in /usr/lib/gcc/i486-linux-gnu/ that matches what
sparse expects.  If I had to set GCC_INTERNAL_INCLUDE on every
invocation, I'd consider that worse than my current workaround.

Either sparse gets smart enough to find the headers [1] or it ships its
own set.  Anything else will continue to fail on one machine or another.

[1] Bernd Petrovitsch sent me this neat one-liner in a private mail:
gcc -v -E - </dev/null 2>&1 >/dev/null | sed -n -e '/^#include <\.\.\.> search starts here:/,/^End of search list\./s/^ \(.*\)/\1/p

We could add that to cgcc to set additional include paths.

Jörn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hard-coded gcc header path

[Bernd Petrovitsch]

On Die, 2008-11-11 at 23:32 +0100, Jörn Engel wrote:
[...]
> Either sparse gets smart enough to find the headers [1] or it ships its
> own set.  Anything else will continue to fail on one machine or another.

I don't think that shipping a copy of .h files from one gcc version will
seriously help people using `pcc` (or any other compiler).
But I'm probably missing something here.

> [1] Bernd Petrovitsch sent me this neat one-liner in a private mail:
> gcc -v -E - </dev/null 2>&1 >/dev/null | sed -n -e '/^#include <\.\.\.> search starts here:/,/^End of search list\./s/^ \(.*\)/\1/p
> 
> We could add that to cgcc to set additional include paths.

And there probably are similar ones for `pcc` or others.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html