On Mon, Nov 16, 2009 at 10:20:40AM -0600, Matthias Klose wrote:
On 16.11.2009 07:24, Carlos O'Donell wrote:
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.cppunrelated: including both -I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/java-gcj/include looks suspicious.
Thanks for noticing!That's probably a left-over from before default-java. I'll simply drop the java-gcj line and hope nothing breaks.
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.
Ah, ok. I'll reword the changelog entry in csound to not call it a workaround but a proper fix.
Thanks for clarifying! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature