Re: Csound build failure in hppa
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler 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
Re: Csound build failure in hppa
On Mon, Nov 16, 2009 at 08:24:54AM -0500, Carlos O'Donell wrote:
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.
Awesome debugging, Carlos.
I have now added your proposed workaround to the csound package.
Regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
Re: Csound build failure in hppa
On 16.11.2009 07:24, Carlos O'Donell wrote:
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler 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
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: [bts-link] source package gcc-snapshot
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package gcc-snapshot > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). > # remote status report for #439616 (http://bugs.debian.org/439616) > # * http://gcc.gnu.org/PR32305 > # * remote status changed: ASSIGNED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 439616 + fixed-upstream Bug #439616 [gcc-snapshot] gcc-snapshot: ICE: stmt marked modified after optimization pass Added tag(s) fixed-upstream. > usertags 439616 - status-ASSIGNED Bug#439616: gcc-snapshot: ICE: stmt marked modified after optimization pass Usertags were: status-ASSIGNED. Usertags are now: . > usertags 439616 + status-RESOLVED resolution-FIXED Bug#439616: gcc-snapshot: ICE: stmt marked modified after optimization pass There were no usertags set. Usertags are now: status-RESOLVED resolution-FIXED. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Csound build failure in hppa
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.cpp
unrelated: 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
signature.asc
Description: Digital signature
[bts-link] source package gcc-snapshot
# # bts-link upstream status pull for source package gcc-snapshot # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #439616 (http://bugs.debian.org/439616) # * http://gcc.gnu.org/PR32305 # * remote status changed: ASSIGNED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 439616 + fixed-upstream usertags 439616 - status-ASSIGNED usertags 439616 + status-RESOLVED resolution-FIXED thanks -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[bts-link] source package gcc-4.3
# # bts-link upstream status pull for source package gcc-4.3 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #498708 (http://bugs.debian.org/498708) # * http://gcc.gnu.org/PR38355 # * remote status changed: UNCONFIRMED -> NEW usertags 498708 - status-UNCONFIRMED usertags 498708 + status-NEW thanks -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Csound build failure in hppa
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.cpp unrelated: including both -I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/java-gcj/include looks suspicious. Just for the record: We included both to support Etch backports which do not have the default-java packages. We considered it superfluous but harmless for newer builds with that extra include line. Etch is old now, so I have dropped support for Etch backports and simplified the config.py file anyway. @Felipe: You may disagree with me on that change - but probably we should then discuss that outside of these other lists :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Results for 4.3.4 (Debian 4.3.4-6) testsuite on mips-unknown-linux-gnu
LAST_UPDATED: Mon Nov 2 00:19:31 UTC 2009 (revision 153796) Target: mips-linux-gnu gcc version 4.3.4 (Debian 4.3.4-6) Native configuration is mips-unknown-linux-gnu === g++ tests === Running target unix === g++ Summary for unix === # of expected passes17671 # of expected failures 92 # of unsupported tests 140 Running target unix/-mabi=64 FAIL: g++.dg/other/anon5.C (test for excess errors) === g++ Summary for unix/-mabi=64 === # of expected passes17642 # of unexpected failures1 # of expected failures 92 # of unsupported tests 142 Running target unix/-mabi=n32 === g++ Summary for unix/-mabi=n32 === # of expected passes17675 # of expected failures 92 # of unsupported tests 140 === g++ Summary === # of expected passes52988 # of unexpected failures1 # of expected failures 276 # of unsupported tests 422 /build/buildd/gcc-4.3-4.3.4/build/gcc/testsuite/g++/../../g++ version 4.3.4 (Debian 4.3.4-6) === gcc tests === Running target unix === gcc Summary for unix === # of expected passes48257 # of expected failures 91 # of untested testcases 35 # of unsupported tests 344 Running target unix/-mabi=64 FAIL: gcc.misc-tests/linkage.c link === gcc Summary for unix/-mabi=64 === # of expected passes47916 # of unexpected failures1 # of expected failures 91 # of untested testcases 35 # of unsupported tests 405 Running target unix/-mabi=n32 FAIL: gcc.c-torture/compile/20080806-1.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/20080806-1.c -O1 (test for excess errors) FAIL: gcc.misc-tests/linkage.c link === gcc Summary for unix/-mabi=n32 === # of expected passes47888 # of unexpected failures3 # of expected failures 91 # of untested testcases 35 # of unsupported tests 410 === gcc Summary === # of expected passes144061 # of unexpected failures4 # of expected failures 273 # of untested testcases 105 # of unsupported tests 1159 /build/buildd/gcc-4.3-4.3.4/build/gcc/xgcc version 4.3.4 (Debian 4.3.4-6) === gfortran tests === Running target unix === gfortran Summary for unix === # of expected passes24738 # of expected failures 3 # of unsupported tests 140 Running target unix/-mabi=64 === gfortran Summary for unix/-mabi=64 === # of expected passes24986 # of expected failures 3 # of unsupported tests 20 Running target unix/-mabi=n32 === gfortran Summary for unix/-mabi=n32 === # of expected passes24986 # of expected failures 3 # of unsupported tests 20 === gfortran Summary === # of expected passes74710 # of expected failures 9 # of unsupported tests 180 /build/buildd/gcc-4.3-4.3.4/build/gcc/testsuite/gfortran/../../gfortran version 4.3.4 (Debian 4.3.4-6) === obj-c++ tests === Running target unix UNRESOLVED: obj-c++.dg/lookup-2.mm compilation failed to produce executable UNRESOLVED: obj-c++.dg/try-catch-2.mm compilation failed to produce executable UNRESOLVED: obj-c++.dg/try-catch-9.mm compilation failed to produce executable === obj-c++ Summary === # of expected passes437 # of expected failures 9 # of unresolved testcases 3 # of unsupported tests 13 /build/buildd/gcc-4.3-4.3.4/build/gcc/testsuite/obj-c++/../../g++ version 4.3.4 (Debian 4.3.4-6) === objc tests === Running target unix === objc Summary === # of expected passes1832 # of expected failures 7 # of unsupported tests 24 /build/buildd/gcc-4.3-4.3.4/build/gcc/xgcc version 4.3.4 (Debian 4.3.4-6) === libgomp tests === Running target unix WARNING: program timed out. FAIL: libgomp.c/appendix-a/a.18.1.c execution test WARNING: program timed out. FAIL: libgomp.fortran/appendix-a/a.18.1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/reference1.f90 -O1 execution test FAIL: libgomp.fortran/reference1.f90 -O2 execution test FAIL: libgomp.fortran/reference1.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/reference1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/reference1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/reference1.f90 -O3 -g execution test FAIL: libgomp.fortran/reference1.f90 -Os execution test === libgomp Summary for u
Re: Csound build failure in hppa
Matthias Klose wrote:
On 16.11.2009 07:24, Carlos O'Donell wrote:
On Sun, Nov 15, 2009 at 11:03 PM, Felipe Sateler
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
Bug#556601: gcc-4.4/sh4: ICE in create_pre_exit, at mode-switching.c:399
Package: gcc-4.4 Version: 4.4.2-2 Severity: important User: debian-...@superh.org Usertags: sh4 Hi, When I built gnustep-base on sh4 , I got the following errors. - mframe.m:1250: warning: cast increases required alignment of target type mframe.m: In function 'retframe_short': mframe.m:863: internal compiler error: in create_pre_exit, at mode-switching.c:399 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[3]: *** [obj/mframe.m.o] Error 1 - I reported upstream, and got the patch which revised this problem. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993 I tested gcc-4.3 and gcc-4.4. Work file. Please apply this patch. Best regards, Nobuhiro -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
