gmane.comp.parsers.sparse

Jörn Engel | 11 Nov 14:56

Bug#505177: Hard-coded gcc header path

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 <at> 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.

(Continue reading)

Johannes Berg | 11 Nov 15:01

Bug#505177: Hard-coded gcc header path

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 <at> 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

Jörn Engel | 11 Nov 15:15

Bug#505177: Hard-coded gcc header path

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, email to debian-bugs-dist-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Pierre Habouzit | 11 Nov 21:13

X-Face

Bug#505177: Hard-coded gcc header path

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 <at> debian.org
OOO                                                http://www.madism.org

Jörn Engel | 11 Nov 21:28

Bug#505177: Hard-coded gcc header path

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, email to debian-bugs-dist-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Morten Welinder | 11 Nov 22:00

Bug#505177: Hard-coded gcc header path

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

Jörn Engel | 11 Nov 23:32

Bug#505177: Hard-coded gcc header path

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

(Continue reading)

Bernd Petrovitsch | 12 Nov 00:10

Bug#505177: Hard-coded gcc header path

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

Bernd Petrovitsch | 11 Nov 15:41

Bug#505177: Hard-coded gcc header path

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

Return

Return to gmane.comp.parsers.sparse.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane