From: Wolfram Quester [mailto:wo...@sigxcpu.org]
>OK, thanks for the link. But the crazy thing is that inkscape
>includes setjmp.h in the code leading to the compiler error
>only via png.h.
You need to look for the #define of _SETJMP_H. Greg's method doesn't work
for that unfortunately, but some header file *other* than setjmp.h is
defining it. IMO that's a big bug in itself, though I've seen similar
things done in code attempting to fake out system header files and
substitute a different implementation.
First check that you really have a valid png.h:
${CC} -c -o foo.o /usr/include/png.h
If this fails your installation has been hacked; reinstall libpng. If it
still fails then the gcc standard pre-include is itself #include'ing
<setjmp.h>. I think someone suggested that on a bug around 2000 - I saw
something to that effect on a recent web search.
Then take the file that fails and temporarily move the #include <png.h> to
the top of the file - make it the first #include. Rebuild. If that fails
you have a local png.h and *it* has been hacked - get a released version.
If it still fails your build script sets the gcc pre-include to #include
<setjmp.h>, fix it.
If it still works move #include <png.h> down towards its previous location
in the file. (Use a binary chop.) This will isolate the #include that is
the top level culprit. Suppose this is <foo.h>, then you should be able to
repro the problem with a simple file of the form:
#include <foo.h>
#include <png.h>
You will probably need to get the gcc -I directives to match those in the
build, but maybe not - just try a simple gcc -c first.
Now it gets more difficult unless it is immediately obvious where foo.h
defines _SETJMP_H. If you can hack on foo.h then you can actually insert
#include <png.h> into the middle and repeat the search in there. If not you
may be able to make a local foo.h and repro the problem in the same way, but
beware the semantics of #include "bar.h" within foo.h - it actually means
'include the bar.h from the directory containing foo.h'. If you can't repro
the problem with a local foo.h it is because you have changed 'the directory
containing foo.h'.
John Bowler <jbow...@acm.org>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
