On 10/30/2013 10:58 AM, Vincent Ryan wrote:
Thanks for the review Chris.
For the record, here’s the updated webrev:
http://cr.openjdk.java.net/~vinnie/8027567/webrev.01/
Change looks fine Vinnie, approved.
Thanks
Dave
On 30 Oct 2013, at 16:57, Chris Hegarty wrote:
The sour
Thanks for the review Chris.
For the record, here’s the updated webrev:
http://cr.openjdk.java.net/~vinnie/8027567/webrev.01/
On 30 Oct 2013, at 16:57, Chris Hegarty wrote:
> The source changes look fine to me, I'm happy to be listed as a reviewer for
> this. ( generated-configure.sh, I jus
The source changes look fine to me, I'm happy to be listed as a reviewer
for this. ( generated-configure.sh, I just assume is ok once
common/autoconf/autogen.sh is run ).
-Chris.
On 30/10/2013 16:24, Vincent Ryan wrote:
Sure. I’ll re-run autogen.sh and submit an updated webrev.
Thanks.
On 3
Sure. I’ll re-run autogen.sh and submit an updated webrev.
Thanks.
On 30 Oct 2013, at 16:15, Erik Joelsson wrote:
> I'm leaving for the day pretty soon, so feel free to push this to tl if you
> have time.
>
> If you do, don't forget to run common/autoconf/autogen.sh and to also submit
> the
I'm leaving for the day pretty soon, so feel free to push this to tl if
you have time.
If you do, don't forget to run common/autoconf/autogen.sh and to also
submit the closed generated-configure.
/Erik
On 2013-10-30 17:07, Vincent Ryan wrote:
Thanks Erik. We’re seeing the issue in TL so it’
Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed
today.
Would you like to take ownership of this issue or shall I push your fix to TL?
On 30 Oct 2013, at 16:00, Erik Joelsson wrote:
> I found a solution that's also more readable. Posting inline since it's so
> small
I found a solution that's also more readable. Posting inline since it's
so small a change:
diff -r 4f2011496393 common/autoconf/basics.m4
--- a/common/autoconf/basics.m4
+++ b/common/autoconf/basics.m4
@@ -514,7 +514,7 @@
if test "x$IS_GNU_MAKE" = x; then
AC_MSG_NOTICE([Found potenti
It seems the problem is with the grep tool used to parse the version
string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the
same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works
better. I will see if I can figure out something that works with both.
/Erik
On 2013-10-
Thanks Chris.
So reverting to the previous version of builds.m4 will fix this issue on
Solaris but will undo
the fix for 8026528 on Windows. Maybe Eric can advise.
On 30 Oct 2013, at 15:05, Chris Hegarty wrote:
> Hi Vinnie,
>
> I have seen this issue myself, kind of funny ;-)
>
> ...
> co
Hi Vinnie,
I have seen this issue myself, kind of funny ;-)
...
configure: Found GNU make at /java/devtools/i386/bin/make, however this
is not version 3.81 or later. (it is: GNU Make 3.81). Ignoring.
configure: error: Cannot find GNU make 3.81 or newer! Please put it in
the path, or add e.g. M
Please review this fix to correct the JDK8 build Configure script.
It reverts a recent change to common/autoconf/basics.m4 that was causing a
build failure on Solaris.
Bug: https://bugs.openjdk.java.net/browse/JDK-8027567
Webrev: http://cr.openjdk.java.net/~vinnie/8027567/
On 2013-10-14 11:25, Erik Joelsson wrote:
Please review the following changes, correcting the conditions for
when to build certain parts of the servicability features. Instead of
guarding them with the OPENJDK variable, they need to be conditioned
on the existence of the source itself.
In hot
On 14/10/2013 7:25 PM, Erik Joelsson wrote:
Please review the following changes, correcting the conditions for when
to build certain parts of the servicability features. Instead of
guarding them with the OPENJDK variable, they need to be conditioned on
the existence of the source itself.
In hots
Looks good! Of course, the proof is in building it.
I can sponsor the hotspot fix.
Thanks,
/Staffan
On 14 okt 2013, at 11:25, Erik Joelsson wrote:
> Please review the following changes, correcting the conditions for when to
> build certain parts of the servicability features. Instead of guard
Please review the following changes, correcting the conditions for when
to build certain parts of the servicability features. Instead of
guarding them with the OPENJDK variable, they need to be conditioned on
the existence of the source itself.
In hotspot, this only fails on Windows. The linux
By setting --with-jobs=1, even with only 1GB of memory, build is
complete. jdk-only itself takes 15 minutes though.
-Max
On 5/6/13 7:41 PM, Erik Joelsson wrote:
On 2013-05-06 13:01, Weijun Wang wrote:
On 5/6/13 3:35 PM, Erik Joelsson wrote:
I would be interested to see the spec.gmk generat
On 2013-05-06 13:01, Weijun Wang wrote:
On 5/6/13 3:35 PM, Erik Joelsson wrote:
I would be interested to see the spec.gmk generated in the build output
directory. Specifically the value of the JOBS variable.
JOBS?=0
I noticed the configure output includes
checking for number of cores... 1
On 5/6/13 3:35 PM, Erik Joelsson wrote:
I would be interested to see the spec.gmk generated in the build output
directory. Specifically the value of the JOBS variable.
JOBS?=0
I noticed the configure output includes
checking for number of cores... 1
checking for memory size... 1002 MB
check
Hi. Weijun.
Try to run it with this option:
./configure --with-jobs=1
On 05.05.2013 17:34, Weijun Wang wrote:
I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as
boot jdk, "bash configure" prompted me to install several packages but
running make shows:
-START-
Building
I would be interested to see the spec.gmk generated in the build output
directory. Specifically the value of the JOBS variable.
/Erik
On 2013-05-05 15:34, Weijun Wang wrote:
I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as
boot jdk, "bash configure" prompted me to install sev
You should run the build with more logging, to see what actually
followed the -j argument.
At a guess I would wonder if the intended argument was empty, so -j is
trying to read the following option as a positive integer, and reporting
the message you see.
-- Jon
On 05/05/2013 06:34 AM, Weij
I just installed a Xubuntu 13.04 32 bit machine. Using 7u21 b13 as boot
jdk, "bash configure" prompted me to install several packages but
running make shows:
-START-
Building Java(TM) for target 'default' in configuration
'linux-x86-normal-server-release'
## Starting langtools
make:
Hi Erik, I did a build of the full forest today and all is well. -Pete
On 11/15/12 10:47 AM, Pete Brunet wrote:
> Erik, I'm sorry. That was bad info. I am building both 7u and 8 and
> this must have been from my 7u sanity build. I tried it again on my 8
> directory and there is no INFO: output
Erik, I'm sorry. That was bad info. I am building both 7u and 8 and
this must have been from my 7u sanity build. I tried it again on my 8
directory and there is no INFO: output.
On 11/15/12 10:29 AM, Pete Brunet wrote:
> I noticed that it's there for make sanity:
>
> INFO: ENABLE_FULL_DEBUG_SYM
I noticed that it's there for make sanity:
INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
INFO: ZIP_DEBUGINFO_FILES=1
INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
INFO: ZIP_DEBUGINFO_FILES=1
Pete
On 11/15/12 10:07 AM, Pete Brunet wrote:
> Hi Erik, I had saved my build log. There is no INFO: section and no
> occurrence
Hi Erik, I had saved my build log. There is no INFO: section and no
occurrences of ZIP_DEBUGINFO_FILES. I'll send you the full log in
separate email. -Pete
On 11/15/12 9:28 AM, Erik Joelsson wrote:
> That is correct, but somehow it is being set since the rule for
> sawindbg.map is triggered. So
That is correct, but somehow it is being set since the rule for
sawindbg.map is triggered. Somewhere in your log, the state of this
variable should be printed like this:
INFO: ZIP_DEBUGINFO_FILES=1
Could you see what it says? Or paste that whole section of INFO:?
/Erik
On 2012-11-15 16:05, P
Hi Erik, I didn't set that. If I understand your note I shouldn't have
to set it, i.e. not setting it results in the default of 1 which matches
the import jdk setting of 1. Is that right?
Pete
On 11/15/12 2:40 AM, Erik Joelsson wrote:
> Did you set ZIP_DEBUGINFO_FILES=0? The default is 1 and I
Did you set ZIP_DEBUGINFO_FILES=0? The default is 1 and I can't see any
obvious way it would change implicitly. The import jdk you are using had
it set to 1 and the import logic expects this setting to match in order
to find the files to import.
/Erik
On 2012-11-15 02:53, Pete Brunet wrote:
I did my first clone/build of jdk8 today and the build failed with...
make[3]: Entering directory
`/cygdrive/c/Users/Pete/JDK8/swing/jdk/make/java/redist/sajdi'
ASSEMBLY_IMPORT: ../../../../build/windows-i586/lib/sa-jdi.jar
/usr/bin/mkdir -p ../../../../build/windows-i586/lib
rm -f ../../../../bu
30 matches
Mail list logo
