Re: RFR: JDK-8192816 Let run-test save exit code

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

Re: RFR: JDK-8191933 Use failure handler in run-test

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 pushed in

Re: RFR: JDK-8191933 Use failure handler in run-test

-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. This is

Re: RFR: JDK-8191933 Use failure handler in run-test

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

Re: RFR: JDK-8189099 JTReg now supports 256 jobs

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

Re: RFR: JDK-8191856 "make clean-test" does not work properly

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

Re: RFR: JDK-8189955 Configuration validation is broken for some types of paths

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

Re: RFR: JDK-8189376 Unsorted $(wildcard) causes instable module-deps.gmk

ld, 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 > +++ b/ma

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman <alan.bate...@oracle.com> 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 fi

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

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) \

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

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

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

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

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

16, 2017 at 10:18 AM, Alan Bateman <alan.bate...@oracle.com> 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 >

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

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

Re: running tests from make causes spurious repo changes

It should be standard practice for whoever does systematic jtreg testing to do it occasionally with the jdk sources mounted in a read-only file system, and ensure all the tests still pass. On Mon, Sep 25, 2017 at 4:54 AM, Maurizio Cimadamore < maurizio.cimadam...@oracle.com> wrote: > > > On

Re: RFR: JDK-8179892 Update build documentation for JDK 9

Thanks! On debian-based systems, it's useful to get dependencies using sudo apt-get -y build-dep openjdk-8-jdk even when building jdk9 or jdk10

Re: RFR: JDK-8175036 All API docs should be built for HTML 5

On Mon, Apr 24, 2017 at 5:06 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > There is also a very strong desire to move to HTML 5 for the JDK > documentation to be able to make use of the accessibility features that are > available. > OK, that's a good reason to do it sooner rather

Re: RFR: JDK-8175036 All API docs should be built for HTML 5

> Does this mean you oppose this change until all Javadoc compiles cleanly > with doclint html5? > > /Magnus > > 22 apr. 2017 kl. 19:11 skrev Martin Buchholz <marti...@google.com>: > > It seems our javadoc is using html constructs that are not valid html5. > If so, we

Re: RFR: JDK-8175036 All API docs should be built for HTML 5

< magnus.ihse.bur...@oracle.com> wrote: > Jon, > > Can you please open a separate bug for this? Just adding --doclint-format > html5 generates a lot of failures, as Martin points out, so it's not > feasible to do as part of this fix. > > /Magnus > > > On 201

Re: RFR: JDK-8175036 All API docs should be built for HTML 5

There would be a global cleanup involved for --doclint-format html5 A CSS expert can probably suggest replacements. [javac] ... src/main/java/util/Deque.java:30: error: attribute border for table only accepts "" or "1", use CSS instead: BORDER [javac] * On Thu, Apr 20, 2017 at 3:42

Re: RFR: JDK-8172912 JTReg concurrency value must be limited

Does your jtreg have the latest javatest? https://bugs.openjdk.java.net/browse/CODETOOLS-7183756 On Fri, Feb 3, 2017 at 4:59 AM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > There is a limitation in jtreg that causes it to fail if called with > -concurrency:X where X is > 50.

jdk-9+153 tarballs have packaging error

I noticed I couldn't use an exploded jdk tarball because some files were not world readable. tar tvzf jdk-9-ea+153_linux-x64_bin.tar.gz ... -rw-r--r-- java_re/java_re 73955 2017-01-18 17:59 jdk-9/include/jni.h -rw-r--r-- java_re/java_re824 2017-01-18 17:59 jdk-9/include/linux/jni_md.h

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis wrote: > > I don't think this can be easily done with the current build system. > Remember for example that even such a sensitive part like jni.h is > still duplicated between the hotspot and the jdk repository: > >

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

Currently the pendulum is swinging away from multiple applications sharing common libraries towards every application being self-contained, perhaps because disk space is dirt cheap and because of the rise of "containers". It may be that much of the packaging of jdks will be picked up by third

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

There's an endless debate about the pros and cons of "dynamic linking". I think it would be best for the JDK to link to system libraries by default, if possible. For a particular JDK image, one can drop a patched libz into a suitable lib directory to override the system one. It should also be

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

I'm actually very happy that we've dropped private patches against libz. And using the system libz seems like the right thing to do on Unix systems, where libz should be ubiquitous. On Wed, Feb 10, 2016 at 4:25 PM, Xueming Shen wrote: > > One of the benefits of moving

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

On Fri, Dec 18, 2015 at 5:35 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2015-12-15 18:25, Martin Buchholz wrote: >> >> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it >> affects interoperability between translation units. It

Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

On Wed, Dec 16, 2015 at 6:08 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2015-12-15 19:38, Martin Buchholz wrote: > Are you talking about JDK-6515172? I was thinking on how to implement a > proper check in the configure script, where calling separate proce

Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

We can fix both JDK-6515172 and JDK-8144312 by doing the autconf detection of how to count the number of allowed processors, then actually measuring what's available during the build, and also fixing the hotspot implemementation of Runtime.availableProcessors.

Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

bur...@oracle.com> wrote: > On 2015-12-15 04:27, Martin Buchholz wrote: >> >> My current mental model is >> configured cpus >= online cpus >= allowed cpus >> In a traditional system they are all the same. >> >> I experimented and saw that cpusets are i

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it affects interoperability between translation units. It would be good to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but that would be a big job. So traditionally the JDK has instead used the functions made

Re: RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

Note that the semantics of stat and access may be subtly different, and that there are many calls to stat in the JDK sources, and they may all be broken on 32-bit systems. I just wrote elsewhere: _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it affects interoperability between

Re: Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

taffinity nproc > sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32 > 4 > +++ exited with 0 +++ > > It would be nice if anyone with access to a system where the number of cpus > is limited in a similar manner to a docker container could run the above > command and see if it > 1

Re: RFR: JDK-8144312: Remove limitations on the default number of jobs in the build

Not to say you shouldn't do this, but I worry that increasingly computing is being done in "containers" where e.g. the number of cpus is doubling every year but only a small number are available to actually be used by a given process. if availableProcessors reports 1 million, what should we do?

Re: [9] RFR of 8140630: java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build

At Google, we've also noticed crashes in Bits.c with recent gcc. Adding nio-dev, since this is not really a build problem. It appears that Bits.c is resorting to undefined behavior, even though there is a long tradition of unaligned access on x86 being permitted by the hardware. My colleague

Re: [9] RFR of 8140630: java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build

ue as you previously suggested. > Suppressing it via the build configuration change is a procedural matter: > work to find the root problem and a real solution continues nonetheless. > > On Nov 4, 2015, at 7:46 PM, Martin Buchholz <marti...@google.com> wrote: > > OK, I lo

Re: hardcoding -m32/-m64 is more harmful than using the toolchain defaults

On Wed, Oct 28, 2015 at 2:32 AM, Andrew Haley <a...@redhat.com> wrote: > On 27/10/15 20:36, Martin Buchholz wrote: > > The world would be a better place if the current x86 32-bit ABI was > > replaced by "x32" > > https://en.wikipedia.org/wiki/X32_ABI > >

Re: hardcoding -m32/-m64 is more harmful than using the toolchain defaults

The world would be a better place if the current x86 32-bit ABI was replaced by "x32" https://en.wikipedia.org/wiki/X32_ABI but it's looking unlikely that we will get there. For starters, all compilers must be rewritten to target x32, and that includes the jdk jits. And that's a big project, one

Re: hardcoding -m32/-m64 is more harmful than using the toolchain defaults

I agree that configure should try to invoke "the compiler" without any flags by default, but make it easy for users to supply them. If some platform like SLES 10 on Linux/ppc64 wants to build 32-bit binaries, assume that this is intended and let it go ahead! Don't just assume the distro

Re: [patch] fix the build with a toolchain with a linker defaulting to ld --as-needed

[+build-dev] On Mon, Oct 19, 2015 at 1:06 PM, Matthias Klose wrote: > Toolchains for some Linux distributions (e.g. Ubuntu, OpenSuse) are > configured to pass --as-needed to the linker by default, only linking with > libraries when required. A common build failure triggered by

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

On Tue, May 26, 2015 at 7:52 PM, Roger Riggs roger.ri...@oracle.com wrote: Hi, Sadly, but not entirely unexpectedly there is an anomaly in the include files: It seems that Windows does not define O_SYNC and O_DSYNC. To make up for the absence

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

I plan to have review comments later today. On Thu, May 21, 2015 at 2:09 PM, Roger Riggs roger.ri...@oracle.com wrote: Please review these native code and build changes to clear compilation warnings. Most are due to mixing unsigned types with signed types or providing the correct type to an

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

It's a good idea to order include statements by system dependencies, jdk dependencies, implementation helpers, BUT order of include statements should never ever matter. If it does, then we have a bug that should be fixed. Every header file should be independently includable, and C files should

Re: Backport multiple toolchains support to JDK8?

I also think that backporting multiple toolchain support seems too risky for jdk8u. At the same time, it may be very useful for others trying to test or port the jdk8u code base (at google, we are motivated by running asan via clang). It would be good if there was a way to share such a backport

Re: IcedTea Build Failures using self as book JDK

[+distro-pkg-dev] On Mon, Mar 23, 2015 at 11:47 AM, Styx, Aaron (US SSA) aaron.s...@baesystems.com wrote: I'm working on porting Java 7 (using IcedTea 2.5.4) to a new OS. I've completed the build once, but when I install what was built to use as the bootstrap JDK and start a fresh build , it

Re: Use of /usr/ccs/bin on Solaris

for configure, using eg. --with-devkit, --with-bootjdk, SED=, GREP= etc. So looking in /usr/ccs/bin instead of failing, is just like the rest of the processing configure does. /Magnus -Dmitry On 2015-03-06 17:50, Magnus Ihse Bursie wrote: On 2015-03-04 22:03, Martin Buchholz wrote: I

Re: Use of /usr/ccs/bin on Solaris

one. So both solutions above looks bad for me. And yes, this all is mostly about *nm* -Dmitry On 2015-03-09 20:03, Martin Buchholz wrote: I support Magnus' strategy. Slightly unrelated, /usr/ccs/bin is a very old directory, and ISTR that it was slowly going away. On SunOS 5.10 I

Re: Use of /usr/ccs/bin on Solaris

On Fri, Mar 6, 2015 at 6:50 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2015-03-04 22:03, Martin Buchholz wrote: I agree that configure should not mess with user's PATH and should auto-find programs in /usr/ccs/bin only as a last resort. It would be reasonable, when

Re: Use of /usr/ccs/bin on Solaris

I agree that configure should not mess with user's PATH and should auto-find programs in /usr/ccs/bin only as a last resort. It would be reasonable, when configure fails on Solaris, to notice that the user does not have /usr/ccs/bin on PATH and suggest appending. On Wed, Mar 4, 2015 at 12:31 AM,

Re: Fwd: Re: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447

Source files should have exactly one trailing newline. find -iregex '.*\.\(java\|txt\|c\|cc\|h\|hpp\|cpp\)$' | xargs perl -0777 -ne 'print Must have exactly one trailing newline: $ARGV\n unless m~[^\n]\Z~s'

Re: Problem building JDK 8

It's a mystery. My own successful config.log snippet with latest jdk8u is below. Why didn't your config.log contain checking for FREETYPE? Maybe a pkg-config problem? Are you doing something crazy like defining LD_LIBRARY_PATH? Someone will need to debug configure, perhaps using bash -x

Re: Problem building JDK 8

Others don't seem to have this problem - you can try looking at config.log and elsewhere trying to figure out what went wrong. On Fri, Dec 19, 2014 at 1:08 AM, Cédric Champeau cedric.champ...@gmail.com wrote: Hi everyone, Some of you may know that we try to test Groovy builds against the

Re: Adding Microbenchmarks to the JDK forest/trees (JEP-230)

On Tue, Dec 2, 2014 at 2:48 PM, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: Do we really want more repositories? Conversely, do we really want bigger repositories? :-) Yes, we want bigger repositories, not more repositories. Put the benchmarks into the existing repo test

Re: RFR: JDK-8065576: Enable pipefail in the shell used by make to better detect build errors

Looks good to me too. I appreciate the high bar for build correctness. I would test with both make 3.81 and 4.x On Wed, Nov 26, 2014 at 6:56 AM, Erik Joelsson erik.joels...@oracle.com wrote: Hello, Please review this build reliability fix. In JDK-8065138, we would have caught the error much

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

this target I filed a separate issue [1] for investigating the use of pipefail. /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8065576 On 2014-11-20 10:34, Daniel Fuchs wrote: On 11/20/14 10:26 AM, Erik Joelsson wrote: Hello, On 2014-11-20 02:20, Martin Buchholz wrote: Amusingly

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

Great! On Fri, Nov 21, 2014 at 3:16 PM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote: On 2014-11-21 22:40, Martin Buchholz wrote: A high-level followup ... Running most text-based OS tools, including sed and sort, is risky because the user's encoding may be different from

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, but the $(SED)s need it too! On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz marti...@google.com wrote: [+ build-dev] I think I see the problem. By default, a Unix pipeline sadly fails only when the last command fails

Re: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes

Philosophically, there's more variation among unices than windows, but windows OSes certainly have some variation over time. Especially if you count the Win98 family, thankfully no longer supported. On Wed, Sep 24, 2014 at 5:39 AM, Magnus Ihse Bursie magnus.ihse.bur...@oracle.com wrote:

Re: OpenJDK9 - build errors on Linux/Ubuntu 12.04

I tried again today ( with jdk9/jdk9-dev ) and everything works now. I believe the problem was fixed by the following, which replaced erroneous references to SetupJava.gmk # HG changeset patch # User erikj # Date 1408611935 -7200 # Thu Aug 21 11:05:35 2014 +0200 # Node ID

Re: OpenJDK9 - build errors on Linux/Ubuntu 12.04

22, 2014 at 4:30 PM, Martin Buchholz marti...@google.com wrote: I've also just lost the ability to build jdk9. I also get uninformative make[1]: *** [main-wrapper] Error 2 Trying to debug, I configure with --with-jobs=1 and run make LOG=debug and that gets me: make[3]: Entering directory

Re: Build summary UX

On Fri, Aug 22, 2014 at 3:10 AM, Erik Joelsson erik.joels...@oracle.com wrote: On 2014-08-22 01:10, Martin Buchholz wrote: 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

Re: OpenJDK9 - build errors on Linux/Ubuntu 12.04

I've also just lost the ability to build jdk9. I also get uninformative make[1]: *** [main-wrapper] Error 2 Trying to debug, I configure with --with-jobs=1 and run make LOG=debug and that gets me: make[3]: Entering directory `...home/martinrb/ws/9up/jdk/make' Tools.gmk:35: SetupJava.gmk: No

Re: Build summary UX

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

Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds

On Mon, Apr 8, 2013 at 5:51 PM, David Holmes david.hol...@oracle.comwrote: 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

new build system doesn't notice modified C source files.

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?)

Re: new build system doesn't notice modified C source files.

and a library was linked, please! On Tue, Mar 26, 2013 at 3:40 PM, Martin Buchholz marti...@google.comwrote: 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

Re: sjavac

(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 gnu.and...@redhat.comwrote: - Original

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

Pushed to jdk8/tl/jdk. I recommend this be backported to jdk7u.

Re: New build system problems

Thanks. Pushed to /hg/jdk8/tl. (only tested on Linux) On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson erik.joels...@oracle.comwrote: ** On 2013-03-04 23:55, Martin Buchholz wrote: On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson erik.joels...@oracle.comwrote: Thanks for the suggestion

Re: New build system problems

Oh dear. Please add in a fixup change if required. On Tue, Mar 5, 2013 at 1:44 PM, David Holmes david.hol...@oracle.comwrote: 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 of the update to closed generated

Re: New build system problems

On Tue, Mar 5, 2013 at 2:36 PM, David Holmes david.hol...@oracle.comwrote: 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

Re: New build system problems

On Tue, Mar 5, 2013 at 3:30 PM, David Holmes david.hol...@oracle.comwrote: 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 the tl gatekeeper and I

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On Mon, Mar 4, 2013 at 3:02 AM, Florian Weimer fwei...@redhat.com 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 product builds. Triggering

Re: New build system problems

On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson erik.joels...@oracle.comwrote: ** 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've refreshed my

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman alan.bate...@oracle.comwrote: 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

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

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) ? strm-msg : +

Suggestion: make help should print list of configurations

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) After

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

) 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 alan.bate...@oracle.comwrote: On 22/02/2013 22:03, Martin Buchholz wrote: Hi Alan, Xueming, build-ers, I'd like you to do a code

Re: j2sdk-image and new build system

On Sat, Feb 23, 2013 at 2:45 AM, Alan Bateman alan.bate...@oracle.comwrote: 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

Re: New build system problems

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 marti...@google.comwrote: I was trying out the shiny new build system. Problem: configure

j2sdk-image and new build system

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.

Re: New build system problems

On Mon, Jan 28, 2013 at 11:58 AM, Kelly O'Hair kelly.oh...@oracle.comwrote: 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

Re: Review Makefile Changes For JDK-8001334 - Remove use of JVM_* functions from java.io code

On Wed, Jan 23, 2013 at 2:20 PM, Dan Xu dan...@oracle.com 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:

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

Thanks for this. I agree with the strategy. I'm hoping build folks and macosx folks also take a look at this hairy change. +LINKFLAG = +ifeq ($(ARCH_DATA_MODEL), 64) +LINKFLAG = -m64 +endif It looks wrong to be specifying toolchain-specific flags here. Also, -m64 is logically a compiler

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

+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); \ +} \

Re: static linking of libgcc on linux ?

This appears to be another case where the hotspot and jdk repo makefiles differ. hotspot does: # statically link libgcc and/or libgcc_s, libgcc does not exist before gcc-3.x. ifneq (${CC_VER_MAJOR}, 2) STATIC_LIBGCC += -static-libgcc endif making it look like the jdk repo makefile is in error.

Re: Pending Character-related work - Character-warnings

On Wed, Jun 30, 2010 at 23:49, Ulf Zibis ulf.zi...@gmx.de wrote: Am 30.06.2010 19:50, schrieb Martin Buchholz: On Wed, Jun 30, 2010 at 01:22, Ulf Zibisulf.zi...@gmx.de  wrote: Am 29.06.2010 02:29, schrieb Martin Buchholz: I tried to do that, but Character.java is one of those classes

Re: Pending Character-related work - Character-warnings

process in general. Can you briefly answer my questions below? Am 01.07.2010 18:13, schrieb Kelly O'Hair: On Jul 1, 2010, at 7:56 AM, Jonathan Gibbons wrote: On 07/01/2010 01:32 AM, Ulf Zibis wrote: Am 01.07.2010 09:38, schrieb Martin Buchholz: On Wed, Jun 30, 2010 at 23:49, Ulf Zibisulf.zi

Re: Pending Character-related work - Character-warnings

On Wed, Jun 30, 2010 at 01:22, Ulf Zibis ulf.zi...@gmx.de wrote: Am 29.06.2010 02:29, schrieb Martin Buchholz: I tried to do that, but Character.java is one of those classes that needs to be compilable by the bootstrap JDK, so this change ist leider nicht moeglich. I think, there should

Re: Makefile help: setting HOTSPOT_EXTRA_SYSDEFS

I'm pasting in the relevant section from the GNU make manual, hoping it helps. 5.7.2 Communicating Variables to a Sub-`make' - Variable values of the top-level `make' can be passed to the sub-`make' through the environment by explicit request. These

Stop linking with -lnsl on Linux

Hi Kelly, I'd like you to do a code review. The JDK links with libnsl on Linux, but this is an unused dependency. Here's a patch to stop linking with it - very similar to the handling of libsocket: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/libnsl I don't know whether libnsl is also

Re: Stop linking with -lnsl on Linux

On Thu, Jun 10, 2010 at 15:46, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: Martin, Do you need a real bug-ID -- it looks like you were not the lucky recipient of 666? Thanks, but Kelly just filed 6960394: Stop linking with -lnsl on Linux

Re: JDK build questions

On Fri, Apr 16, 2010 at 10:24, David Dabbs dmda...@gmail.com wrote: Hello. My apologies if these questions are OT for this list. On the premise that building my own binaries could yield performance improvements versus the Sun(Oracle)-provided binaries I've decided to tinker with building

Re: JDK build questions

On Fri, Apr 16, 2010 at 12:09, David Dabbs dmda...@gmail.com wrote: * If so, is it possible to build using Intel's compiler? You'll probably need to port, and to modify some underlying assumptions. I don't recommend it. I'm not sure I understand your reference to port. The Intel compiler

Re: Unhappy about test/ProblemList.txt

On Tue, Mar 30, 2010 at 09:11, Kelly O'Hair kelly.oh...@sun.com wrote: On Mar 29, 2010, at 7:04 PM, Martin Buchholz wrote: On Mon, Mar 29, 2010 at 17:14, Kelly O'Hair kelly.oh...@sun.com wrote: Jonathan is working on some changes to jtreg that may allow many of the tests on the ProblemList

Re: No rule to make foo.cpp needed by foo.o ???

On Tue, Dec 22, 2009 at 21:55, David Holmes - Sun Microsystems No it's not that simple. If I update 5 files the first build reports the 1st is missing, the second reports the 2nd is missing and so forth and a lot longer than 30 seconds has passed in between. :( Then it's probably a different

Re: No rule to make foo.cpp needed by foo.o ???

On Mon, Dec 21, 2009 at 18:42, David Holmes - Sun Microsystems david.hol...@sun.com wrote: Igor Nekrestyanov said the following on 12/22/09 11:45: Check the output of gnumake -dd looking for everything related to files in question. It will tell you why rules are not fired. Surprisingly the

Re: the trustAnchors parameter must be non-empty for jdk7-jaxp-m5.zip

I'm seeing this problem too, building openjdk7-b76. Seems like a P2 bug to me. I *can* download using wget. Is there an easy way to download all the bundles I need? http://kenai.com/projects/jdk7-drops/downloads has bundles, but they appear to be incomplete. Martin On Sun, Nov 22, 2009 at 21:45,

Re: the trustAnchors parameter must be non-empty for jdk7-jaxp-m5.zip

On Tue, Nov 24, 2009 at 15:39, Kelly O'Hair kelly.oh...@sun.com wrote: What version of ant are you using? I think I'm using 1.7.0

Re: Need reviewers - jdk testing changes 6888927

On Tue, Nov 3, 2009 at 18:45, Jonathan Gibbons jonathan.gibb...@sun.comwrote: The thing that stood out to me was the use of SLASH_JAVA which is something of a Sun legacy which doesn't apply to folk outside Sun. I've been using SLASH_JAVA because it simplifies the job of organizing my jdk

<    1   2   3   >