On Thu, Jun 08, 2006 at 08:48:01AM +1000, Ben Burton wrote: > > Hi, > > > Probably a solution would be including libgcj7-dev. > > It does. It build-depends on libgcj-dev (>= 4:4.1.0), which brings in > libgcj7-dev. > > >From the amd64 build log (which failed in this way): > > Unpacking libgcj7-dev (from .../libgcj7-dev_4.1.1-2_amd64.deb) ... > > I suspect my problem is -I/usr/lib/jvm/java-gcj/include ; the symlinks > that point from there to the real jni.h are provided by java-gcj-compat > and java-gcj-compat-dev, which I don't build-depend on. It seems the > real filenames are now gcc-version-dependent, and look something like > /usr/lib/gcc/i486-linux-gnu/4.1.1/include/jni.h, which I expect gcc > won't find unless your gcc and gcj versions are the same. > > So it seems I need to build-depend on java-gcj-compat-dev if I don't > want to hard-code the (gcc-version-dependent) path to jni.h.
No, its enough to rebuild the package with the new gcc package pointing to gcc-4.1 installed. Then the needed compiler internal dir will be automatically included and it will find the jni.h. java-gcj-compat-dev is not needed and not deliberated. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]