Matthias Klose wrote:
On 16.11.2009 07:24, Carlos O'Donell wrote:
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler<fsate...@gmail.com>
wrote:
I think the analysis it is wrong, because after the scons clean
stage, the
cache is deleted. Relevant section from debian/cdbs/1/class/scons.mk:
scons-clean::
$(DEB_SCONS_INVOKE) $(DEB_SCONS_CLEAN_TARGET)
$(DEB_SCONS_OPTIONS)
--keep-going --clean || true
rm -f debian/stamp-scons-build
rm -rf .sconf_temp/
rm -f .sconsign.dblite config.log
The cache are .scon*.
As can be seen in the build log, when scons uses a cached value (like
in the
install stage), it prints: Checking for foo... (cached) no.
However, in the buildd log the build stage shows no (cached) responses.
Thanks, I hadn't realized that this code was deleting the scons cache.
With this knowlege I went back, and verified a couple of things:
1) Verified that the custom.py (using md5sum) is installed before
scons is run.
2) Verified using strace that scons opens custom.py.
3) Verified using a compiler wrapper that the invocation by
configure.CheckHeader() contains the correct include path.
The following is the compiler invocation that configure.CheckHeader()
uses when looking for jni.h.
hppa-linux-gnu-g++ -o .sconf_temp/conftest_26.o -c -fexceptions
-Wno-format -DGNU_GETTEXT -g -fomit-frame-pointer -freorder-blocks
-DLINUX -DPIPES -DUSE_DOUBLE -DHAVE_SOCKETS
-DHAVE_PTHREAD_BARRIER_INIT -DHAVE_SYNC_LOCK_TEST_AND_SET -I. -IH
-I/usr/include/lua5.1 -I/usr/include/tcl -I/usr/include/tcl8.4
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/java-gcj/include
-I/usr/local/include -I/usr/include -I/usr/include
-I/usr/X11R6/include .sconf_temp/conftest_26.cpp
unrelated: including both -I/usr/lib/jvm/default-java/include
-I/usr/lib/jvm/java-gcj/include looks suspicious.
When I compile this I get:
In file included from .sconf_temp/conftest_26.cpp:2:
/usr/lib/jvm/default-java/include/jni.h:52:20: error: jni_md.h: No
such file or directory
This is why the build fails to detect jni.h, not because the jni.h
file isn't there but because additional header files are missing.
Adding: customCPPPATH.append('/usr/lib/jvm/default-java/include/linux')
to debian/custom.py causes the build to complete successfully. This is
a possible workaround.
not just a workaround; both /usr/lib/jvm/default-java/include and
/usr/lib/jvm/default-java/include/linux have to be included. There is no
garantee that the jni_md.h header is also found in the
/usr/lib/jvm/default-java/include directory.
Thanks for clarifying this. As noted by Jonas, this has been fixed.
Thanks Carlos and Matthias!!
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
