Hello,
JDK_FILTER was supposed to work, but I see now that it doesn't. That is
a bug and needs to be fixed.
Yes, all dependencies are recompiled as make cannot know if there was an
api change or not. To work around that, you can do "make java.desktop"
or "make java.base" to have the compilat
On 2014-08-21 10:19, Erik Joelsson wrote:
Hello,
JDK_FILTER was supposed to work, but I see now that it doesn't. That
is a bug and needs to be fixed.
Actually, I think you can still use this as java.desktop was correctly
recompiled and the failure happened afterwards. If you pair it with
"
Hi,
Currently get_source.sh verifies hg version but it does not work well
except English environment.
For example, my language environment is Japanese and get_source.sh prints
error message:
--
ERROR: Could not determine Mercurial version of /usr/bin/hg
--
The cause of this issue is following in
Hello,
Please review this minor fix for hprof demo on aix. When reorganizing
the source code for modules, we put a copy of
src/aix/porting/porting_aix.* in each of the two locations using it. One
of them was the hprof demo. This patch removes the now unused extra
source dir declaration for hp
Hello,
Recent changes seem to have caused the build on my Jenkins prototypes to
no longer work.
Here is a transcript:
$ hg clone --rev 70e378877c6af42790df8ae3492a66e1e0ed00e7 --noupdate
http://hg.openjdk.java.net/jdk9/dev
/scratch/jenkins/workspaces/jdk9/8M59VYK6V7NQ/OS/linux/arch/x86-64
reques
The hotspot makefiles are trying to invoke nmake on linux? That looks
really weird and I have not seen it before.
/Erik
On 2014-08-21 15:04, Eric McCorkle wrote:
Hello,
Recent changes seem to have caused the build on my Jenkins prototypes to
no longer work.
Here is a transcript:
$ hg clone
Any idea as to why they think they're on windows?
On 08/21/14 09:22, Erik Joelsson wrote:
> The hotspot makefiles are trying to invoke nmake on linux? That looks
> really weird and I have not seen it before.
>
> /Erik
>
> On 2014-08-21 15:04, Eric McCorkle wrote:
>> Hello,
>>
>> Recent changes s
Hi Erik:
Please review this minor fix for hprof demo on aix. When reorganizing
the source code for modules, we put a copy of
src/aix/porting/porting_aix.* in each of the two locations using it.
One of them was the hprof demo. This patch removes the now unused
extra source dir declaration for
Hi,
The recent update of jdk9/jdk9 build scripts had significantly
deteriorated the usability of the build summary. This what was printed
before:
--- 8< -
Building OpenJDK for target 'default' in configuration
'linux-x86_64-normal-s
Possible lead: it seems hotspot/make/defs.make defaults to Windows if it
doesn't recognize the $OS variable.
1) It should throw an error in that case
2) I checked on Jenkins, and the PATH seems fine, and uname -s run as a
script works fine. Could it be something about make is causing uname -s
to
Eric McCorkle wrote:
Any idea as to why they think they're on windows?
On 08/21/14 09:22, Erik Joelsson wrote:
The hotspot makefiles are trying to invoke nmake on linux? That looks
really weird and I have not seen it before.
[ ... snip ...]
configure ran OK, and knew it was on a linux box. T
On 08/21/14 11:12, Tim Bell wrote:
> Eric McCorkle wrote:
>
>> Any idea as to why they think they're on windows?
>>
>> On 08/21/14 09:22, Erik Joelsson wrote:
>> The hotspot makefiles are trying to invoke nmake on linux? That looks
>> really weird and I have not seen it before.
> [ ... snip ...]
>
Hello Aleksey,
As I have tried to explain a couple of times now: The jdk8 build built
each repository in sequence (much like the jdk7 build did). Because of
this it made sense to add messages about which repository was being
built and measure the time each took. The new jdk9 build is not
repo
Hello,
Please review this small patch. In Javadoc.gmk the javadoc command is
defined with an explicit mx flag. However, configure is already
calculating a suitable mx for a "large" java process, which is already
provided in the JAVA variable. This patch removes the redundant mx flag
from Java
Hi,
On Solaris the HS_ALT_MAKE variable was not passed to vm.make when creating the
mapfiles which lead to mapfile-ext not being found and later a linker error due
to symbols declared in the extra mapfile not being found.
The hotspot makefiles are .. interesting .. yes.
The proposed solution
On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote:
Hi,
On Solaris the HS_ALT_MAKE variable was not passed to vm.make when
creating the mapfiles which lead to mapfile-ext not being found and
later a linker error due to symbols declared in the extra mapfile not
being found.
The hotspot makefiles
Thank you for the quick reply Dan!
A new webrev with your suggested change is available here:
http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/
/Jesper
Daniel D. Daugherty skrev 21/8/14 18:42:
On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote:
Hi,
On Solaris the HS_ALT_MAKE variable was
Hello all;
This is a very small fix suggested by bitter_fox which forces English
localization for the 'hg version' message which is parsed by get_source.
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8055772/0/webrev/
jbsbug: https://bugs.openjdk.java.net/browse/JDK-8055772
Reminder: 8055331
Hi Erik:
Please review this small patch. In Javadoc.gmk the javadoc command is
defined with an explicit mx flag. However, configure is already
calculating a suitable mx for a "large" java process, which is already
provided in the JAVA variable. This patch removes the redundant mx
flag from Ja
$ sh ./configure --with-debug_level=slowdebug --disable-zip-debug-info
$ CONF=linux-x86_64-normal-server-slowdebug make STRIP_POLICY=no_strip
POST_STRIP_CMD="" HOTSPOT_BUILD_JOBS=10 STATIC_CXX="false"
ALT_SDT_H=undefined ALT_OBJCOPY=none LOG=debug DEBUG_BINARIES=true images
profiles
... time
Looks good.
Do we know if the headless=true is actually needed?
Mike
On Aug 21 2014, at 10:16 , Tim Bell wrote:
> Hi Erik:
>
>> Please review this small patch. In Javadoc.gmk the javadoc command is
>> defined with an explicit mx flag. However, configure is already calculating
>> a suitable
Hi Mike:
This is a very small fix suggested by bitter_fox which forces English
localization for the 'hg version' message which is parsed by get_source.
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8055772/0/webrev/
jbsbug: https://bugs.openjdk.java.net/browse/JDK-8055772
Looks good. Appr
> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/
make/solaris/Makefile
No comments.
make/solaris/makefiles/buildtree.make
No comments.
A product build with the above changes shows this:
$ cat solaris_amd64_compiler2/product/mapfile_ext
# Extended set of symbol
Yep, that's how it's supposed to look :)
Thanks!
/Jesper
Daniel D. Daugherty skrev 21/8/14 19:43:
> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/
make/solaris/Makefile
No comments.
make/solaris/makefiles/buildtree.make
No comments.
A product build with the above changes
Serial execution is useful for both resource-constrained environments and
for folks trying to profile the build itself. Serial build is also likely
to be optimal if you are optimizing for total energy used rather than total
wall clock time.
On Thu, Aug 21, 2014 at 8:39 AM, Erik Joelsson
wrote:
I like the new finer grained parallelism in general (builds are faster),
but I do find the default output more confusing because it is harder to
see the warning messages go rushing past.
Of course, a good solution would be to work on addressing the warnings
so that there are no warning message
Trying build-dev@openjdk.java.net
I think the jtreg-dev was a wrong DL to begin with.
Medi
From: Medi Montaseri
Sent: Thursday, August 21, 2014 3:03 PM
To: jtreg-...@openjdk.java.net
Subject: How to set build version
Hi,
I currently get the following version inf
27 matches
Mail list logo
