Re: Csound build failure in hppa

[Matthias Klose <doko@debian.org>]

On 16.11.2009 07:24, Carlos O'Donell wrote:
> On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler<fsateler@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.

  Matthias