Changeset: bf6ee1d9127e
Author:martin
Date: 2008-06-10 16:30 -0700
URL: http://hg.openjdk.java.net/jdk7/build/rev/bf6ee1d9127e
6710904: COMMON_BUILD_ARGUMENTS needs PREVIOUS_..._VERSION settings
Reviewed-by: ohair, tbell
! make/Defs-internal.gmk
Changeset: a5c908deb70f
Author:martin
Date: 2008-06-10 16:31 -0700
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a5c908deb70f
6710907: vestigial MOTIF references from Makefiles
Reviewed-by: ohair, tbell
! make/sun/jawt/Makefile
Changeset: a0d703b249f0
Author:martin
Date
Hello,
I try to port OpenJDK to the OS VxWorks. The Problem is, that i cant
compile it on a VxWorks-Machine, so i have to cross-compile it from a Linux
machine. What I've read so far is, that i have to use openembedded to
successfully cross compile OpenJDK.
All sources I've found, were dated 2008
Hello,
i get the following error when i try to compile openjdk7:
/home/marty/openjdk/build/linux-i586/tmp/sun/sun.awt/jawt/obj/jawt.o
-L/home/marty/openjdk/build/linux-i586/lib/i386 -lawt
-L/home/marty/openjdk/build/linux-i586/lib/i386/headless -lmawt
-ljava -L/home/marty/openjdk/build/linux
Am 6. März 2012 13:05 schrieb David Holmes :
> On 6/03/2012 8:16 PM, martin burtscher wrote:
>
>> Hello,
>>
>> i get the following error when i try to compile openjdk7:
>>
>>/home/marty/openjdk/build/**linux-i586/tmp/sun/sun.awt/**
>> jawt/obj/jawt.
Hello,
can anybody confirm, that cross compiling is working with make flags:
CROSS_COMPILE_ARCH
ALT_COMPILER_PATH?
With confirm i mean tested and not just read in readme, because theres also
a BUILD_HEADLESS_ONLY in the readme which doesn't work.
Thanks.
Martin
ve to compile all the
packages?
Thanks,
Martin
On Tue, Dec 4, 2012 at 4:37 PM, David Holmes wrote:
> /java/embedded/users/dh198349/**profiles/builds/b66/se-linux-**
> i586-ea/jdk/classes/java/lang/**Integer.class: major version 52 is newer
> than 51, the highest major version supported by this compiler.
>
Consider (just for jdk development pu
ed later when the new build system is obligatory.
---
+/* Initialize xx_parentPathv[] */
It's not called xx_anything any more.
---
+shutItDown();
How about renaming to usageError() ?
---
+r = sscanf (argv[argc-1], "%d:%d", &fdin, &fdout);
How about
+res = readFully (fdin, &magic, sizeof(magic));
+if (res != 4 || magic != magicNumber()) {
s/4/sizeof(magic)/
---
+extern int errno;
Delete.
---
+#define ALLOC(X,Y) { \
+void *mptr; \
+mptr = malloc (Y); \
+if (mptr == 0) { \
+error (fdout, ERR_MALLOC); \
+} \
On Wed, Jan 23, 2013 at 2:20 PM, Dan Xu wrote:
> Hi,
>
> I have a fix for JDK-8001334 to remove JVM_* functions and replace with
> direct system calls. It introduces newmake filechangesin IO area especially
> on Windows platform. Please help review and approve them.
>
> Bug:
> https://jbs.oracle
I was trying out the shiny new build system.
Problem: configure is not executable - must run bash ./configure
It's traditional for configure scripts to be executable.
Problem: Your life is hell if you have a non-compiler "cl" command on your
PATH, even on Linux.
checking for cl... /usr/bin/cl
co
On Mon, Jan 28, 2013 at 11:58 AM, Kelly O'Hair wrote:
> I would like configure to be executable too, but openjdk has a tradition
> of not allowing executable files in the source repos.
>
>
> To avoid the possibility of any executable binaries being put into the
> OpenJDK "source" repositories, we
export zlib symbols from libzip.so
- so need to tell makefiles to use linker script unconditionally
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/
On Fri, Feb 22, 2013 at 2:15 PM, Xueming Shen wrote:
> **
> Here is the bugid you will need.
>
> 8008759: Do not let internal JDK zlib symbols leak out of fastdebug
> libzip.so
>
>
Thanks! webrev updated.
"j2" is so 2001. Before freezing the shiny new build system, consider
taking the opportunity to rename
"j2sdk" => "jdk"
"j2re" => "jre"
globally in the new Makefiles.
I'm having fun with the shiny new build system.
It took me a while to discover that "make help" was exceptionally helpful.
However, I was interested in passing a configuration to CONF= and was
annoyed there was no clue what to provide. (I wasn't even sure exactly
what a "configuration" was)
Afte
at com.sun.tools.javac.main.Main.compile(Main.java:356)
at com.sun.tools.javac.Main.compile(Main.java:76)
at com.sun.tools.javac.Main.main(Main.java:61)
On Sat, Feb 23, 2013 at 3:51 AM, Alan Bateman wrote:
> On 22/02/2013 22:03, Martin Buchholz wrote:
>
> Hi Alan, Xueming, build-ers,
On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman wrote:
> On 23/02/2013 10:29, David Holmes wrote:
>
>>
>> Just be aware there's a lot more involved in doing this than just
>> changing one a name in a makefile.
>>
>> You beat to me too! Yes, there are likely a lot of scripts and paths
> that assume
Hi Erik, Tim, Kelly
Here's a proposed fix for you to review:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/
Martin
On Fri, Jan 25, 2013 at 3:51 PM, Martin Buchholz wrote:
> I was trying out the shiny new build system.
>
> Problem: configure is not exe
Kelly,
Thanks. I think we agree.
I think we have consensus that my change is an improvement and should be
committed.
Can I haz approval?
I'm not brave enough to try to change the default for all mapfiles,
although I would support Kelly or anyone else who tries.
Martin
On Mon, Feb 25, 20
On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff <
dmitry.samers...@oracle.com> wrote:
>
> 2. Not all versions of test support == as equation. It's better to use
> single one. and I would prefer to have quotes around xmacosx and
> xwindows just for consistency. i.e.
>
> if test "x$OPENJDK_TARGET
s.
Do we have consensus on that?
Martin
On Sun, Feb 24, 2013 at 12:19 AM, Dmitry Samersoff <
dmitry.samers...@oracle.com> wrote:
>
> 1. for windows compiler checklist become: cl cc gcc
>
> I'm not sure we need to check for cc on windows, also gcc build on
> windows is not sup
I have another iteration of this change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/
that adds exciting new exception detail message for the InternalError I was
scratching my head about earlier.
-msg = strm->msg;
+msg = ((strm->msg != NULL) ? str
On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman wrote:
> The update to make/java/zip/Makefile looks good to me, we should have
> done it a long time ago. I assume you are pushing ahead on this because you
> want to push it to jdk7u-dev (as it's not interesting to jdk8 now because
> of the new buil
On Mon, Mar 4, 2013 at 3:02 AM, Florian Weimer wrote:
> On 02/22/2013 11:03 PM, Martin Buchholz wrote:
>
> I've finally figured out why fastdebug jdk occasionally gives
>> InternalError
>> in the zip code.
>>
>
> In the distant past, I also saw this with pr
On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote:
> **
> Thanks for the suggestion Martin!
>
> I created 8009376 for this and will try to get it done.
>
There's already a bug for this:
8006988 : build-infra: Configure fails if 'cl' is in path on linux
I'
Thanks.
Pushed to /hg/jdk8/tl.
(only tested on Linux)
On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson wrote:
> **
> On 2013-03-04 23:55, Martin Buchholz wrote:
>
>
>
> On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote:
>
>> Thanks for the suggestion Martin!
>>
Oh dear.
Please add in a fixup change if required.
On Tue, Mar 5, 2013 at 1:44 PM, David Holmes wrote:
> Martin, Erik,
>
> On 6/03/2013 7:19 AM, Martin Buchholz wrote:
>
>> Thanks.
>> Pushed to /hg/jdk8/tl.
>>
>
> There has to be a corresponding push
On Tue, Mar 5, 2013 at 1:53 PM, David Holmes wrote:
>
> You needed to have a jdk8 Reviewer listed for this change. Erik is a
> Committer not Reviewer.
>
>
That's not obvious. Isn't it jcheck's job to make sure any required
approvals are in?
I should have included more eyeball names on the Reviewe
On Tue, Mar 5, 2013 at 2:36 PM, David Holmes wrote:
>
> Sorry but that is completely unacceptable. If you are providing changes
> that obviously impact multiple platforms (ie there are platform specific
> changes) then they _must_ be tested on all platforms. If the external
> author/committer can
On Tue, Mar 5, 2013 at 3:30 PM, David Holmes wrote:
> On 6/03/2013 9:17 AM, Martin Buchholz wrote:
>
>>
>> IMO the right approach is to improve processes so that bad commits don't
>> cause other developers to lose time. Once upon a time, I was actually
>>
On Tue, Mar 5, 2013 at 4:36 PM, David Holmes wrote:
>
>>> I disagree. The submitter should be responsible for the "right" amount
>> of
>> upfront testing.
>>
>
> Now you are confusing me :) You disagree but say the responsibility is on
> the submitter. Well I certainly agree with that! Our diffe
Pushed to jdk8/tl/jdk.
I recommend this be backported to jdk7u.
While you're there, consider checking/modfying all of the jdk tools to
accept either both or neither of "-cp" and "-classpath". javap is the
command I'm thinking of.
(As I've complained about recently)
Not all jdk commands (e.g. javap, and apparently sjavac) consistently
support either both or neither of '-cp' and '-classpath' as synonyms.
But that's being fixed.
On Fri, Mar 15, 2013 at 10:57 AM, Andrew Hughes wrote:
>
>
> - Original Message -
> > Th
I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and
did "make images" but no actual compilation happened.
(I guess I currently need to do a clean rebuild? Which is a serious bug?)
If I modify an ordinary JDK source file (like StringBuilder.java), then all
files are recompiled, even those that don't have any compile-time
dependency on StringBuilder.
## Starting jdk
Compiling 9412 files for BUILD_JDK
I'd like to see instead
Compiling 103 files for BUILD_JDK
library was linked,
please!
On Tue, Mar 26, 2013 at 3:40 PM, Martin Buchholz wrote:
> I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and
> did "make images" but no actual compilation happened.
> (I guess I currently need to do a clean rebuild? Which is a serious bug?)
>
On Mon, Apr 8, 2013 at 5:51 PM, David Holmes wrote:
> On 9/04/2013 2:59 AM, Andrew Hughes wrote:
>
>>
>> Well, if I push it, it will be, no?
>>
>
> Testing comes before pushing - thank you.
>
This issue keeps coming up.
Non-Oracle committers have no access to the Oracle automated testing
submiss
x27;t have to ever worry about build failures getting through.
>>
>> In the meantime I don't think my request to work with others to ensure
>> broader test coverage of build changes is unreasonable.
>>
>> I can't force anyone's cooperation I can only request
On Thu, May 2, 2013 at 9:06 AM, Andrew Hughes wrote:
> HotSpot is even more of a problem because not being able to commit directly
> risks people losing credit for the work they've done and, with an open
> source
> project, credit is the only reward.
>
It *is* possible with mercurial to create/i
On Thu, 26 Nov 2020 15:18:04 GMT, Aleksey Shipilev wrote:
> Sample build log sizes:
>
> PPC64 fastdebug, 200 kilobytes:
>
> https://builds.shipilev.net/openjdk-jdk/build-logs/build-linux-ppc64le-fastdebug.log
>
> S390X fastdebug, 20 megabytes!
>
> https://builds.shipilev.net/openjdk-jdk
On Thu, 7 Jan 2021 09:34:09 GMT, Matthias Baesken wrote:
>> Hello, for a while the AIX build fails with the following error in the
>> harfbuzz build
>> 1500-004: (U) INTERNAL COMPILER ERROR while compiling
>> OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_c
t/4c86e46d
11u backport:
http://cr.openjdk.java.net/~mdoerr/8256810_build_11u/webrev.00/
Please review.
Best regards,
Martin
Hi Roland,
thanks for letting me know. My plan was to backport both changes in the
original order, but I'm fine if you do change to the new version at once.
May I ask you to flag both issues as backported once you're done?
Best regards,
Martin
> -Original Message-
&
Hi Roland,
> Sure. Is a comment stating that this was backported what you have in mind?
Preferrably comment + link "backportet by" to your backport issue.
> Would you mind reviewing my RFR given you've already taken a look at
> this area?
I'll take a look.
Best rega
jdk/commit/51d325e6
11u backport:
http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/
Please review.
Best regards,
Martin
Hi Götz,
thanks for the review.
Best regards,
Martin
From: Lindenmaier, Goetz
Sent: Freitag, 15. Januar 2021 11:29
To: Doerr, Martin ; jdk-updates-...@openjdk.java.net;
build-dev@openjdk.java.net
Cc: Langer, Christoph
Subject: RE: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when
Hi Christoph,
thanks for reviewing, testing and for the approval. Pushed.
Best regards,
Martin
From: Langer, Christoph
Sent: Samstag, 16. Januar 2021 12:03
To: Doerr, Martin ; jdk-updates-...@openjdk.java.net;
build-dev@openjdk.java.net
Cc: Lindenmaier, Goetz
Subject: RE: [11u] RFR: 8257633
On Mon, 25 Jan 2021 14:00:42 GMT, Andrew Leonard wrote:
>> @andrew-m-leonard (Seems I can't get github to tag you???)
>>
>> That sounds good. I think you could move the IncludeCustomExtension to after
>> all *.conf files, to future-proof it and to make it a bit more consistent --
>> "first inc
On Wed, 28 Apr 2021 17:23:18 GMT, Andrew Leonard wrote:
>> Signed-off-by: Andrew Leonard
>
> Andrew Leonard has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views will show differences
> compared to the previous content of the PR. The p
On Thu, 7 Oct 2021 08:27:47 GMT, Niklas Radomski wrote:
>> Port the Z garbage collector
>> ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux
>> on ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with two
> additional commits since the last revis
On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote:
>> Port the Z garbage collector
>> ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux
>> on ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with three
> additional commits since the last rev
On Thu, 11 Nov 2021 11:32:49 GMT, Roman Kennke wrote:
>> Port the Shenandoah garbage collector
>> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
>> ppc64le.
>
> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
>
>> 81: LIRGenerator*
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
Nice work! Looks correct.
For others: Note that this change already contains feedback from my offline
revie
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line
536:
> 534: if (!preserve_g
On Thu, 18 Nov 2021 17:22:28 GMT, Niklas Radomski wrote:
>> Port the Shenandoah garbage collector
>> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
>> ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with one
> additional commit since the las
On Tue, 11 Jan 2022 16:53:05 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Thu, 20 Jan 2022 22:51:28 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Fri, 21 Jan 2022 17:35:14 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Fri, 21 Jan 2022 09:28:27 GMT, Martin Doerr wrote:
>> Tyler Steele has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert changes to jfrThreadSampler.cpp
>> - Update copyright years. Remove
On Tue, 1 Feb 2022 21:36:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Wed, 2 Feb 2022 16:30:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Wed, 2 Feb 2022 22:42:47 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Fri, 4 Feb 2022 16:05:02 GMT, Tyler Steele wrote:
> I like the idea of adding the IBM copyright line more judiciously, and only
> when the changes I've made are significant. ProblemList.txt, where I've made
> a single line change, stands out in my mind as an example of where this line
> cou
On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK 👋
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
The difficulties encountered trying to run langtools10 in a jdk9 suggests
that the jdk9 module model is too restrictive. I've long lobbied for
treating langtools as just another collection of ordinary programs that
happen to be written in java and should not need special support from the
host jdk.
oices.
On Mon, Oct 16, 2017 at 10:18 AM, Alan Bateman
wrote:
> On 16/10/2017 16:41, Martin Buchholz wrote:
>
>> The difficulties encountered trying to run langtools10 in a jdk9 suggests
>> that the jdk9 module model is too restrictive. I've long lobbied for
>> tr
What's the canonical way to list all upgradeable modules?
There's a list in JEP 261, but naturally we can't consider it authoritative.
I was surprised that even java --describe-module doesn't tell me whether a
module is upgradeable.
I was surprised to see JEP 261 say that java.compiler is upgrade
1.
The upgrade module path. This path contains compiled definitions of
modules that will be observed in preference to the compiled definitions of
any *upgradeable modules* that are present in (3) and (4). See the Java
SE Platform for the designation of which standard modules are upg
I tried to figure out how this patch actually works. At first I thought we
were "shading" (renaming all the packages in the source files) but now I
think we're merely renaming the modules by appending ".interim" to the
names. But that looks like cheating to me - we're not allowed to have
multiple
Does $(INTERIM_LANGTOOLS_MODULES_COMMA) need to be repeated below? I would
think you could drop it from --limit-modules
+INTERIM_LANGTOOLS_ARGS := \
+--limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
+--add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \
On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman
wrote:
> On 17/10/2017 17:53, Martin Buchholz wrote:
>
> I tried to figure out how this patch actually works. At first I thought
> we were "shading" (renaming all the packages in the source files) but now I
> think we'
Hi,
we only support 64 bit on s390. Seems like the code could be cleaned up or
updated. Thanks for looking into it.
Best regards,
Martin
-Original Message-
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-boun...@openjdk.java.net]
On Behalf Of David Holmes
Sent: Montag, 23
ng the build, causing race conditions.
>
> The bug analysis and patch is contributed by Martin Buchholz.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189376
> Patch inline:
> diff --git a/make/common/Modules.gmk b/make/common/Modules.gmk
> --- a/make/common/Modules.gmk
>
Not a review, but ... a note that some of us have to live on slow
filesystems with deeply nested paths where canonicalizing paths becomes a
bottleneck.
On Wed, Oct 25, 2017 at 8:03 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> We are validating that the topdir we're using when
Should all phony targets be listed in a .PHONY line?
On Fri, Nov 24, 2017 at 2:45 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> With the new layout of make run-test, the test-results and test-support
> directories are not removed by "make clean-test", and not even "make clean".
Looks good.
On Fri, Nov 24, 2017 at 2:22 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> From the bug report:
> "According to research by Jonathan Gibbons , JTReg now supports 256 jobs,
> in contrast to the older limit of 50 jobs. This limit is enforced in the
> make files, and i
Every jtreg run would like to have the most helpful failure handling
possible. Should some/all of this be pushed into jtreg itself instead of
the makefiles?
On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> The jtreg failure handler needs to be used wh
t; On 2017-11-28 23:03, Martin Buchholz wrote:
>
> Every jtreg run would like to have the most helpful failure handling
> possible. Should some/all of this be pushed into jtreg itself instead of
> the makefiles?
>
> As I understand things, jtreg has a kind of plugin structure. Th
l with the overall goal of moving
> stuff
> into jtreg when it is practical to do so.
>
> -- Jon
>
>
> On 11/28/2017 02:03 PM, Martin Buchholz wrote:
>
>> Every jtreg run would like to have the most helpful failure handling
>> possible. Should some/all of this be push
Yeah, tr is a stupid little utility that it would be nice to get away from.
It's possible that env LC_ALL=C tr will fix your ASCII character set
problem.
On Thu, Nov 30, 2017 at 1:45 PM, Tim Bell wrote:
> Magnus:
>
> Looks good.
>
> On well-behaving unix systems, tr -c '[a-z]' '_' would
>>
>>>
Mark, thanks for implementing my little feature request. Looks good to me.
Aside: we only support running configure under bash, but as a result the
configure script is now a strange mixture of bashisms and 1980-isms.
On Mon, Dec 18, 2017 at 2:41 PM, wrote:
> Bug: https://bugs.openjdk.java.net/
On Mon, Dec 18, 2017 at 3:50 PM, wrote:
> 2017/12/18 15:36:03 -0800, Martin Buchholz :
> > Mark, thanks for implementing my little feature request. Looks good to
> me.
>
> I didn't know you'd requested this -- is there an existing issue?
>
https://bugs.openjdk.java.net/browse/JDK-8189761
I agree configure should not fail if javah is not found. A high quality
configure test would first check if javac -h works, then fall back to javah
if that works, regardless of the boot jdk's version.
On Tue, Jan 2, 2018 at 6:33 AM, Nir Lisker wrote:
> I'm trying to build OpenJDK 11 as instruct
[build-dev redirect]
On Tue, Jan 9, 2018 at 2:16 AM, Ao Qi wrote:
> Hi,
>
> I found it failed to build zero. The repository I used is
> http://hg.openjdk.java.net/jdk/jdk
> I get this error (on Ubuntu 16.04 x86):
>
> $ sh configure --with-boot-jdk=/my-path-to-jdk9 --with-jvm-variants=zero
> $ m
Differing projects have come to different conclusions about whether to
include a generated configure.
But the standard seems to be to include one. The mantra is: "./configure &&
make" without an autoconf step. The number of people building openjdk is
much larger than the number of people patching
Another possibility is implementing the invariant that configure is
generated via autoconf 2.69 by a mercurial commit hook.
On Thu, Jan 18, 2018 at 10:18 PM, Martin Buchholz
wrote:
> Differing projects have come to different conclusions about whether to
> include a generated configure.
&
[+build-dev]
On Fri, Jan 19, 2018 at 9:48 AM, Stefan Knorr wrote:
> Hi,
>
> I noticed that the page at http://openjdk.java.net/install/ does not
> mention how to install OpenJDK on SUSE-based distros (openSUSE and SUSE
> Linux Enterprise/SLE). Would it be possible to add that information?
>
> Fo
On Fri, Jan 19, 2018 at 11:16 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> On 01/19/2018 07:43 PM, Martin Buchholz wrote:
> > [+build-dev]
>
> Does this really fit here? It's not related to building OpenJDK but
> rather just installing, is
On Thu, Jan 18, 2018 at 11:49 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2018-01-19 08:08, Erik Helin wrote:
>
>> On 01/19/2018 07:18 AM, Martin Buchholz wrote:
>>
>>> Differing projects have come to different conclusions about whether to
>&
if I
cd test/jdk && make all ...
I get
Test results: no tests selected
...
Summary: jdk_default
TEST STATS: name=jdk_default run=0 pass=0 fail=0
---
Also I find I have to define PRODUCT_HOME and JT_HOME as environment
variables - make variables are insufficient
Ahh, I had forgotten we are in the middle of a transition to "run-test".
I need to read doc/testing.md.
On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> Use make run-test TEST="test/jdk" instead.
>
> /Magnus
>
dashes.
On Mon, Feb 5, 2018 at 12:22 PM, Martin Buchholz
wrote:
> Ahh, I had forgotten we are in the middle of a transition to "run-test".
> I need to read doc/testing.md.
>
> On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wro
I agree. Once you make something lazy-initted you have a concurrency
problem. And there's no CAS or lock on the filesystem. What happens if
two configure processes run at exactly the same time, perhaps even with
different versions of autoconf? If you lazy-generate configure, it must be
written
Looking at
https://packages.ubuntu.com/search?suite=all§ion=all&arch=any&keywords=openjdk-9-jdk&searchon=names
it seems like Ubuntu ships whatever openjdk-9 is available at time of
creation of a specific version, and doesn't update it afterwards, not even
for the quarterly security patches.
On Thu
On Tue, Feb 20, 2018 at 11:09 PM, Abhijit Saha wrote:
> It's a retroactive review request. Fix has been integrated after reviewed
> internally.
>
> jdk11+1 (first build of jdk11) was promoted with incorrect Release Date.
> Need to be updated with correct GA date as per internal release roadmap.
>
http://www.oracle.com/pls/topic/lookup?ctx=javase10 currently takes you to
java 9 docs
On Mon, Feb 26, 2018 at 12:38 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> It was recently discovered that some URLs in JDK 10 still pointed to the
> "javase9" URL base.
>
> I intend to push
1 - 100 of 378 matches
Mail list logo
