May 2007 - core-libs-dev

jar launcher not able to handle -march=nocona
by Petteri Räty 30 May '07

30 May '07

<<<Finished Recursively making audio all @ Mon May 28 19:55:30 EEST 2007. >>>Recursively making dcpr all @ Mon May 28 19:55:30 EEST 2007 ... make[4]: Entering directory `/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/j2se/make/sun/dcpr' /bin/mkdir -p /var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/build/linux-i586/classes /bin/echo -e "Copying classes from /opt/sun-jdk-1.7.0.0_alpha13/jre/lib/rt.jar" Copying classes from /opt/sun-jdk-1.7.0.0_alpha13/jre/lib/rt.jar (cd /var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/build/linux-i586/classes ; /var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/build/linux-i586/bin/jar xvf /opt/sun-jdk-1.7.0.0_alpha13/jre/lib/rt.jar sun/dc) /bin/sh: line 1: 17527 Segmentation fault /var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/build/linux-i586/bin/jar xvf /opt/sun-jdk-1.7.0.0_alpha13/jre/lib/rt.jar sun/dc make[4]: *** [copy-closed-src-classes] Error 139 make[4]: Leaving directory `/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/j2se/make/sun/dcpr' make[3]: *** [all] Error 1 make[3]: Leaving directory `/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/j2se/make/sun' make[2]: *** [all] Error 1 make[2]: Leaving directory `/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/j2se/make' make[1]: *** [j2se-build] Error 2 make[1]: Leaving directory `/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/make' make: *** [dev-build] Error 2 !!! ERROR: dev-java/openjdk-1.7.0.0_alpha13 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile openjdk-1.7.0.0_alpha13.ebuild, line 120: Called die In this case I am building with "-O2 -march=nocona -g" and using the following patches: http://overlays.gentoo.org/proj/java/browser/java-experimental/dev-java/ope… Here is the bt I get. The line numbers probably don't match because of O2: (gdb) set args xvf /opt/sun-jdk-1.7.0.0_alpha13/jre/lib/rt.jar sun/dc (gdb) run Starting program: /var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/build/linux-i586/bin/jar xvf /opt/sun-jdk-1.7.0.0_alpha13/jre/lib/rt.jar sun/dc [Thread debugging using libthread_db enabled] [New Thread -1209010512 (LWP 14559)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209010512 (LWP 14559)] hyperthreading_support () at ../../../src/solaris/bin/java_md.c:1189 1189 if (_launcher_debug) { (gdb) bt #0 hyperthreading_support () at ../../../src/solaris/bin/java_md.c:1189 #1 0x0804daf3 in logical_processors_per_package () at ../../../src/solaris/bin/java_md.c:1259 #2 0x0804db97 in physical_processors () at ../../../src/solaris/bin/java_md.c:1284 #3 0x0804dc05 in linux_i586_ServerClassMachine () at ../../../src/solaris/bin/java_md.c:1349 #4 0x0804dc66 in ServerClassMachine () at ../../../src/solaris/bin/java_md.c:1376 #5 0x0804a434 in CheckJvmType (pargc=0xbff8f660, argv=0xbff8f664, speculative=0 '\0') at ../../../src/share/bin/java.c:709 #6 0x0804e0df in CreateExecutionEnvironment (_argcp=0xbff8f660, _argvp=0xbff8f664, jrepath=0xbff8e5d8 "/var/tmp/portage/dev-java/openjdk-1.7.0.0_alpha13/work/o/control/build/linux-i586", so_jrepath=4096, jvmpath=0xbff8d5d8 "", so_jvmpath=4096, original_argv=0x8052008) at ../../../src/solaris/bin/java_md.c:295 #7 0x0804bbd2 in main (argc=0, argv=0x8052098) at ../../../src/share/bin/java.c:253 I am in the process of trying to replicate this without -O2 to get a back trace but any thoughts on the issue would be appreciated. Regards, Petteri

2 3

Fixing compiler warnings
by Petteri Räty 24 May '07

24 May '07

This silences some QA warnings given by GCC. I don't have access to Solaris so it would probably be safest to test there before committing although man gettimeofday is claiming that the function is quite standard: CONFORMING TO SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not settimeofday(). I haven't signed the SCA but this is hardly copyrightable. Regards, Petteri -- Gentoo/Java project lead

2 1

test message
by Tom Marble 19 May '07

19 May '07

All: Please ignore this test message. --Tom

1 0

Fw: [PATCH] Allow usage of external zlib copy
by Diego 'Flameeyes' Pettenò 11 May '07

11 May '07

After Phil Race's suggestion, I'm forwarding this to core-libs, as it might be more appropriate. Begin forwarded message: Date: Fri, 11 May 2007 07:39:39 +0200 From: Diego 'Flameeyes' Pettenò <flameeyes(a)gmail.com> To: build-dev(a)openjdk.java.net Subject: [PATCH] Allow usage of external zlib copy Most distributions have policies about using external copies of libraries whenever possible. OpenJDK ships with a series of libraries that are usually available on a system, like zlib and jpeg, thus breaking such a policy. The attached patch tries to correct part of this by letting use of external zlib copy when passing EXTERNAL_ZLIB=true at the make process. I'm also gonna work on a similar patch to use external jpeg library (that will likely depend on this one because of some of the files touched being the same). -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/

1 0

[PATCH] Missing free() after tempnam() call (java.util.zip)
by Diego 'Flameeyes' Pettenò 10 May '07

10 May '07

(I hope this is the right mailing list for this, if it isn't, please tell me where to post this :) ) I was looking at one warning coming from ld about the use of tmpname() function rather than something like mkstemp, and while looking at that, I found that the string returned by tempnam() was not being freed after use. I admit I don't have a Solaris box at hand to check if it's true there too, but at least Linux's and FreeBSD's versions of tempnam() allocates with malloc() the returned string. (My lack of a Solaris box at the moment is what stops me from trying to use mkstemp() already; I'll try to prepare a virtual machine with that as soon as I can). The attached very very trivial patch fixes the leak by freeing the string after use; it's a very small leak, but if I understand the code well (but I won't bet I do) if a software uses that code repeatedly, it might be significant. Anyway, I hope this can be of help. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/

1 1