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
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.
My previous comment that adding --config=force caused the build to
succeed was wrong, as I had been playing with custom.py, and had not
realized that I had added the above path during my experimentation and
that *this* was the cause of the successful build.
On hppa that symlink is missing and this causes your build problem.
The symlink should be provided by java-gcj-compat source when building
all of the java-gcj-compat* packages.
This appears to be a bug in the java-gcj-compat package (CC'ing debian-gcc).
The java-gcj-compat package has disabled code for architectures that
only use gcj4.4, and this includes hppa.
Enabling the disabled code in java-gcj-compat causes
java-gcj-compat-headless to conflict with gcj-jre-headless (which
provides the same directory /usr/lib/jvm/java-gcj).
So my question is this: Is java-gcj-compat required for gcj4.4? Does
gcj-jre-headless need to provide the appropriate symlinks that
java-gcj-compat used to provide?
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
