On 05/18/2017 04:12 PM, Matthias Klose wrote:
Hi, I don't know why the jtreg check was tightened or changes, however it breaks
the build on FHS based systems, like on most Linux distros.
/usr/bin/jtreg
/usr/share/java/jtreg.jar
What is this supposed to check? Currenlty it expects a JT_H
Hi, I don't know why the jtreg check was tightened or changes, however it breaks
the build on FHS based systems, like on most Linux distros.
/usr/bin/jtreg
/usr/share/java/jtreg.jar
What is this supposed to check? Currenlty it expects a JT_HOME, but apparently
only uses the locaton of the jar
Hi Thomas,
On 19/05/2017 4:39 AM, Thomas Stüfe wrote:
Okay, I regenerated the generated-configure.sh and the double
definitions for -DSUPPORTS_CLOCK_MONOTONIC disappeared. So the
generated-configure.sh you posted was just outdated.
Not sure how but as long as it is fixed. :)
However, the deb
Okay, I regenerated the generated-configure.sh and the double definitions
for -DSUPPORTS_CLOCK_MONOTONIC disappeared. So the generated-configure.sh
you posted was just outdated.
However, the debug output still appears twice: configure: No
CLOCK_GETTIME_IN_LIBRT
AC_MSG_NOTICE([No CLOCK_GETTIME_IN_
On 5/18/2017 10:10 AM, Brad R. Wetmore wrote:
As long as pandoc for windows is always a windows native thing and
not provided by cygwin this seems good. A quick googling indicates
that cygwin currently does not provide pandoc so should be fine then.
You are correct in that pandoc is not prov
On 5/18/2017 12:27 AM, Magnus Ihse Bursie wrote:
Looks good. Formally, I believe someone else needs to review it.
Hm...I would have expected your "Contributed-by" and my review would be
sufficient (what we do for sponsoring an "author" change), but looks
like Erik did review also so we shou
On 5/18/17 8:30 AM, Mandy Chung wrote:
On May 18, 2017, at 12:54 AM, Magnus Ihse Bursie
wrote:
When the build system tries to figure out which modules that should be included by the javadoc
build, it locates the set of modules "required" by already included modules,
starting from an initia
> On May 18, 2017, at 12:54 AM, Magnus Ihse Bursie
> wrote:
>
> When the build system tries to figure out which modules that should be
> included by the javadoc build, it locates the set of modules "required" by
> already included modules, starting from an initial set and repeating
> recursi
Even better! :)
/Magnus
> 18 maj 2017 kl. 14:26 skrev Erik Joelsson :
>
> Did a slight adjustment, adding double dollars when referencing JIB_JAR
> inside a macro body. This makes the code safer in certain cases.
>
> diff -r 91ac8096f365 make/RunTests.gmk
> --- a/make/RunTests.gmk
> +++ b/make
Hi David, Magnus,
compiles and works fine on AIX, but as mentioned before off-list to David I
see this stdout:
configure: No CLOCK_GETTIME_IN_LIBRT
configure: No CLOCK_GETTIME_IN_LIBRT
Also, the -DSUPPORTS_CLOCK_MONOTONIC appears twice on the command line.
Full compile command looks like this:
Well, sort of. The versions of MacOS, XCode, and Command Line Tools should
match, in the sense that any certain version of MacOS requires a compatible
version of XCode, which in its turn requires a compatible version of the
Command Line Tools.
It is thus not possible to keep an older XCode when
Hi,
Thanks, this worked. The order of installation of Xcode IDE and the Command
line tools , seem to make a difference.
BR,
Soundararajan
> On 18-May-2017, at 18:03, Lennart Börjeson wrote:
>
> Have you installed the Command Line Tools for XCode? That package is
> essential.
>
> If you hav
I can build on MacOS Sierra (10.12.5), XCode 8.3.2.
I have to disable ”warnings as errors”, though. (bash configure
--disable-warnings-as-errors)
/Lennart
> 18 maj 2017 kl. 14:27 skrev Erik Joelsson :
>
> Hello,
>
> I think you should still be able to install some 7.X version of Xcode and
>
Have you installed the Command Line Tools for XCode? That package is essential.
If you haven’t installed it, you can get it by the command:
sudo xcode-select --install
> 18 maj 2017 kl. 14:21 skrev Dakshinamoorthi, Soundararajan
> :
>
> Hi,
>
> I am trying to build java9 in mac OS X Sierra (
Hello,
I think you should still be able to install some 7.X version of Xcode
and IIRC that should work better. I have not yet heard of a successful
build on Xcode 8.
/Erik
On 2017-05-18 14:21, Dakshinamoorthi, Soundararajan wrote:
Hi,
I am trying to build java9 in mac OS X Sierra (10.12).
Looks good to me.
/Magnus
On 2017-05-18 14:18, Erik Joelsson wrote:
The new run-test target does not work with the new jib test
dependencies feature in jdk10-hs. The fix is small, just adding
JIB_JAR to the command line for jtreg if present, as is done in
make/TestCommon.gmk.
Bug: https://b
Did a slight adjustment, adding double dollars when referencing JIB_JAR
inside a macro body. This makes the code safer in certain cases.
diff -r 91ac8096f365 make/RunTests.gmk
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -358,6 +358,10 @@
$1_JTREG_BASIC_OPTIONS += -nativepath:$$($1_JT
Hi,
I am trying to build java9 in mac OS X Sierra (10.12). As per the building.md,
we need Xcode 6.3 to be installed to build JDK. But this version of the OS
doesn’t seem to support it. So i installed the latest Xcode (8.3). The error i
get when running make is
“Unable to find
I tried twea
Hi Erik,
This looks good, thanks for fixing this.
Thanks,
Christian
> On May 18, 2017, at 8:18 AM, Erik Joelsson wrote:
>
> The new run-test target does not work with the new jib test dependencies
> feature in jdk10-hs. The fix is small, just adding JIB_JAR to the command
> line for jtreg if
The new run-test target does not work with the new jib test dependencies
feature in jdk10-hs. The fix is small, just adding JIB_JAR to the
command line for jtreg if present, as is done in make/TestCommon.gmk.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180600
Patch:
diff -r 91ac8096f365 ma
Looks good.
/Erik
On 2017-05-18 09:54, Magnus Ihse Bursie wrote:
When the build system tries to figure out which modules that should be
included by the javadoc build, it locates the set of modules
"required" by already included modules, starting from an initial set
and repeating recursively
On 2017-05-18 09:35, David Holmes wrote:
On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
On 2017-05-18 08:25, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
webrevs:
Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
Build changes look good
As long as pandoc for windows is always a windows native thing and not
provided by cygwin this seems good. A quick googling indicates that
cygwin currently does not provide pandoc so should be fine then.
/Erik
On 2017-05-18 09:27, Magnus Ihse Bursie wrote:
Looks good. Formally, I believe som
So far I have looked, it seems jdk.jconsole uses this classes for
windows only. These classes are specified in
JConsole.java where it checks (for non-windows, it will come as
GTKLookAndFeel)
String systemLaF = UIManager.getSystemLookAndFeelClassName();
if (systemLaF.equals("com.sun.java.swing.p
When the build system tries to figure out which modules that should be
included by the javadoc build, it locates the set of modules "required"
by already included modules, starting from an initial set and repeating
recursively (a method which we unfortunately called "transitive").
However, for
Looks fine.
Thanks,
David
On 18/05/2017 5:40 PM, Magnus Ihse Bursie wrote:
The extLink taglet that was introduced in JDK-8178725 has a "&" in the
base URL segment, which needs to be expressed as "&" instead.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180486
WebRev:
http://cr.openjdk.java.n
The extLink taglet that was introduced in JDK-8178725 has a "&" in the
base URL segment, which needs to be expressed as "&" instead.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180486
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8180486-extLink-taglet-needs-escaped-ampersand/webrev.01
/Mag
On 18/05/2017 5:32 PM, Magnus Ihse Bursie wrote:
On 2017-05-18 08:25, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
webrevs:
Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
Build changes look good.
Thanks Magnus! I just realized I left in
On 2017-05-18 08:25, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8174231
webrevs:
Build-related: http://cr.openjdk.java.net/~dholmes/8174231/webrev.top/
Build changes look good.
/Magnus
hotspot:
http://cr.openjdk.java.net/~dholmes/8174231/webrev.hotspot/
Firs
Looks good. Formally, I believe someone else needs to review it.
/Magnus
On 2017-05-18 02:07, Brad R. Wetmore wrote:
Magnus,
I've added your suggested fix to spec.gmk.in, which is the minor tweak
to add @FIXPATH@ to allow pandoc to run on windows builds.
https://bugs.openjdk.java.net/br
On 2017-05-17 17:14, Erik Joelsson wrote:
Hah, that seems like a reasonable solution to me. The index page
generation shouldn't be heavy enough to be a problem here.
It's not the generation in itself, it's its dependencies that are heavy,
compared to plain docs-jdk-specs.
But, most use cases
31 matches
Mail list logo
