Re: RFR: 8260289: Unable to customize module lists after change JDK-8258411 [v2]

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

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

fyi Build reproducibility has become more important over the years. That is especially true at Google, where reproducible builds are more efficient. We have modified versions of various archivers that can generate deterministic metadata in the archive. And that includes the "jar" command. The file

Re: [8u] RFR: 8227397: Add --with-extra-asflags configure option

LGTM On Fri, Jan 17, 2020 at 2:59 AM Severin Gehwolf wrote: > Hi, > > Could I get a second review from an JDK 8u Reviewer, please? > > Thanks, > Severin > > On Mon, 2019-09-30 at 11:36 +0200, Magnus Ihse Bursie wrote: > > On 2019-09-27 17:48, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I

Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and SPARC Ports

On Sun, Dec 15, 2019 at 1:49 AM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > > I tried both variants as below, but autoconf is failing me when I try to > regenerate > configure. > You didn't say how. > > Can anyone remind me what the proper way of regenerating the

Re: RFR: 8234835 Use UTF-8 charset in make support Java code

Looks good ... but please add a comment pointing to https://pandoc.org/MANUAL.html """Pandoc uses the UTF-8 character encoding for both input and output.""" On Wed, Dec 4, 2019 at 3:30 PM Dan Smith wrote: > > On Dec 3, 2019, at 5:24 PM, Jonathan Gibbons < > jonathan.gibb...@oracle.com> wrote: >

Re: RFR: 8234835 Use UTF-8 charset in make support Java code

The ubiquitous use of UTF-8 is one of the few clear successes in the software world. In 2019, most software projects should declare that all their source files are encoded in UTF-8, not US-ASCII. On Wed, Nov 27, 2019 at 9:04 AM Dan Smith wrote: > Please review this patch to make explicit use of

Re: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system

I recall years ago running into troubles with regex character ranges, e.g. https://unix.stackexchange.com/questions/15980/does-should-lc-collate-affect-character-ranges but my build script wrapper has been setting LC_ALL=C for a long time, and I set LC_COLLATE=C in my normal use shell environment

Re: RFR: JDK-8231594: Configure fails on some Linux systems

Looks good, ... although I question whether any Unix program other than the shell itself should be trying to do tilde-path-expansion. Consider fixing the code by deleting it. On Fri, Sep 27, 2019 at 3:42 PM Erik Joelsson wrote: > In my recent change JDK-8206125, I introduced a bash conditional

Re: RFR: 8227397: Add --with-extra-asflags configure option

Martin, > > On Mon, 2019-07-08 at 10:42 -0700, Martin Buchholz wrote: > > (not really a review ...) > > > > I'm confused because the assembler is invoked when compiling any sort of > source file - C, C++, or .s/.S. > > Wouldn't we want assembler flags passed uniformly, n

Re: RFR: 8227397: Add --with-extra-asflags configure option

(not really a review ...) I'm confused because the assembler is invoked when compiling any sort of source file - C, C++, or .s/.S. Wouldn't we want assembler flags passed uniformly, no matter when the assembler is invoked? It looks like this patch only affects compilation of .s/.S files in

Re: jdk 14 version string scheme changed?

> > [1] https://openjdk.java.net/jeps/223 > On 2019-06-14 12:25, Martin Buchholz wrote: > > The first jdk14 build reports: > openjdk full version "14-ea+1-1" > while jdk13 has: > openjdk full version "13-ea+25" > > The trailing "-1" looks like a bug - is it intentional? > >

jdk 14 version string scheme changed?

The first jdk14 build reports: openjdk full version "14-ea+1-1" while jdk13 has: openjdk full version "13-ea+25" The trailing "-1" looks like a bug - is it intentional?

Re: RFR: JDK-8225392: Comparison builds are failing due to cacerts file

erts and their aliases are > unchanged, the output cacerts will always be the same. I can send out a > code review today. > > > > Thanks, > > Max > > > >> On Jun 12, 2019, at 10:59 AM, Weijun Wang > wrote: > >> > >> Good idea about the creat

Re: RFR: 8221610: Resurrect (legacy) JRE bundle target

On Thu, Mar 28, 2019 at 4:55 AM Alan Bateman wrote: > I'm curious who these "stakeholders" are and what they use these JRE > bundle for? As you know, moving to a modular platform has blurred the > historical distinction between what we knew as the JRE and JDK in the > past. Are they concerned

Re: RFR: [8u] Build failed on Ubuntu 18.04 due to deprecated-declarations warnings

Probably it's because glibc deprecated readdir, and we don't have --disable-warnings-as-errors by default? (I think warnings should not be errors except as opt-in by openjdk developers/maintainers) On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley wrote: > On 3/19/19 12:25 PM, Jie Fu wrote: > > To

Re: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a build

Looks good to me. On Fri, Mar 15, 2019 at 12:05 PM Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/ > > This one applies pretty much as-is, when adjustments are made to use the >

Re: Faster rebuild with GNU gold linker

https://openjdk.markmail.org/thread/q3layufiyjivu42c On Tue, Feb 19, 2019 at 5:03 PM Ioi Lam wrote: > For the impatient engineers > > I did some measurement between the default GNU linker "ld" vs "ld.gold". > I am trying to get the fastest rebuild time after I modify one cpp file. > With

Re: Running micro benchmark results in 'Error: Unable to access jarfile'

On Tue, Feb 19, 2019 at 10:37 AM Jorn Vernee wrote: > > I'm a committer on project Panama, but I'm not sure if I have write > access to jdk/jdk as well. You don't https://openjdk.java.net/census#jvernee

Re: RFR: JDK-8218413 make reconfigure ignores configure-time AUTOCONF environment variable

Looks good to me. On Mon, Feb 11, 2019 at 3:42 AM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > From the bug report: > > "Suppose PATH points to an out-of date autoconf. > We can use the AUTOCONF environment variable with configure to override > finding autoconf on PATH, but that

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

I agree with Andrew Hughes. On Wed, Jan 30, 2019 at 9:27 AM Andrew Hughes wrote: > > I'm aware of the benefits of using gold, and also occasional issues with > it, but that's not the debate here. It's already perfectly possible to > build with gold by using --with-ldflags="-fuse-ld=gold", as

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

Another, more productionized, version of my benchmark: processors=12 g++ (Debian 7.3.0-5) 7.3.0 --- -fuse-ld=bfd --- 6.559 user 1.180 system 7.740 total --- -fuse-ld=gold --- 4.575 user 0.600 system 5.176 total --- -fuse-ld=gold -Wl,-threads --- 9.355 user 5.062 system 4.289 total ---

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

On Fri, Jan 25, 2019 at 10:07 AM Andrew Haley wrote: > > On 1/25/19 5:01 PM, Martin Buchholz wrote: > > I re-ran my linker performance experiment using configure > > --with-native-debug-symbols="internal" > > lld is a big winner here: > > It looks to m

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

In our own wrappers around configure, we've introduced the concept of a "developer mode". But this thread suggests there are 3 populations of users invoking configure: 1. release engineers 2. hotspot developers 3. java library developers Category 1 doesn't care about edit-compile-debug cycle -

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

m 326% cpu 1.146 total On Thu, Jan 24, 2019 at 10:49 AM Martin Buchholz wrote: > > Here's an experiment using the 3 competing open source linkers to link > hotspot. This confirms that lld is faster than gold is faster than > bfd, but is the one second saving worth the engineering ef

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

On Thu, Jan 24, 2019 at 2:28 PM Erik Joelsson wrote: > > Do the constituent object files have debugging information? Sub-second > > processing times for ~350 MiB of output are rather impressive. > > Ah! That must be it. I just tried with --with-native-debug-symbols=none > and then I get

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

s is in line with what hotspot developers I have talked to also see > (and they have similar hardware). > > My workstation has a few years on it, but surely machines haven't gotten > 17 times faster? There must be something else at play here. > > /Erik > > On 2019-01-24 10:4

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

Here's an experiment using the 3 competing open source linkers to link hotspot. This confirms that lld is faster than gold is faster than bfd, but is the one second saving worth the engineering effort? $ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for linker in bfd gold lld; do

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

On Thu, Jan 24, 2019 at 7:46 AM Magnus Ihse Bursie wrote: > So, we already tacitly assume a specific linker with the gcc toolchain; we > have just not made that check explicitly. gcc runs on almost every system, but it's harder to replace the compiler than the linker, so gcc ends up being

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

Getting into the business of choosing the linker is big trouble. The system default toolchain may have already chosen a linker. BFD might be configured to have either bfd ld or gold. # Handle --enable-gold, --enable-ld. # --disable-gold [--enable-ld] # Build only ld. Default option. #

Re: RFR 8214794 : java.specification.version should be only the major version number

> > LGTM

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson wrote: > > I missed one thing then looking at this. In TimeZone_md.c it should be > > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but > > I need to change this one line before pushing. > > Hi Alan, > > Yes feel free to modify

Re: Stop using precompiled headers for Linux?

I vote for disabling precompiled headers by default - they simply make the build less reliable. It seemed like precompiled headers did not work when using different optimization levels for different source files, which in turn was needed for building with clang, so I've been disabling precompiled

Re: Linux + Clang + execstack

Unfortunately, my gmail marked Arthur's emails to this thread as spam, with ensuing confusion. I retargeted this fix to the new bug 8209817: stack is executable when building with Clang on Linux http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/

Re: Failed to compile OpenJDK 12-dev by LLVM 8 for X86 with OpenJDK 10 boot jdk

We haven't yet agreed on how to fix https://bugs.openjdk.java.net/browse/JDK-8186780 You can locally apply any of the fixes from the bug report and you can give an opinion on which fix you like. On Mon, Sep 17, 2018 at 6:26 AM, Leslie Zhai wrote: >

Re: Linux + Clang + execstack

On Thu, Sep 13, 2018 at 12:48 PM, Magnus Ihse Bursie wrote: >> >> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch > > I'm not entirely happy, but it'll have to do. The problem here is that the > underlying structure of the flags handling is still not good so this >

Re: Linux + Clang + execstack

On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie wrote: > On 2018-09-05 20:59, Martin Buchholz wrote: > > So ... Magnus, are you happy with the current state of the proposed patch? > > I'm sorry Martin, but I can't figure out what the current state is. I tried > backtrack

Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86

https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

hat about ASan? > https://bugs.openjdk.java.net/browse/JDK-8189800 > > > 在 2018年09月06日 09:12, Martin Buchholz 写道: > >> it's difficult to use llvm tools like sanitizers on openjdk sources, >> because of the "cheating" - relying on undefined behavior, and the J

Status of unshuffle

The unshuffle infrastructure in ./bin/unshuffle_patch.sh ./bin/unshuffle_list.txt is highly version specific, and has naturally bitrotted. Maybe it should simply be removed from openjdk-current. Maybe a more flexible version of unshuffle could be built that would work for any source and dest

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

lang analyzer, sanitizer > and libfuzzer towards hotspot and jdk native library? Thanks! > > > 在 2018年09月06日 02:10, Martin Buchholz 写道: > >> We seem to have some confusion about flags for C vs. flags for C++. Most >> flags for most toolchains apply to both C and C++, so

Re: Linux + Clang + execstack

So ... Magnus, are you happy with the current state of the proposed patch? On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > For the gcc toolchain this can not be the case: > # Minimum supported linker versions, empty means unspecified >

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

We seem to have some confusion about flags for C vs. flags for C++. Most flags for most toolchains apply to both C and C++, so it's understandable that we want to unify them. But some flags, notably -std, are language-specific. We have both EXTRA_CFLAGS and EXTRA_CXXFLAGS, so we should expect

Re: Linux + Clang + execstack

on Linux should be treated equally by gcc and clang The test TestCheckJDK and supporting infrastructure should stop advertising itself as only dealing with libraries. Maybe add GNU-stack annotations to all the Linux .s files as well? On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz wrote: > I think

Re: Linux + Clang + execstack

I think we can all agree that passing flags to the linker to ensure non-executable stack is the right thing to do. But there's a question whether *also* adding something to our assembly language source files will be worth doing. Neither mechanism is sure to work. For the linker flag, we need to

Re: RFR (S) 8208665: Amend cross-compilation docs with qemu-debootstrap recipe

Aleksey, your use of "base" platform seems a bit unusual. Elsewhere in the same document, it's referred to as "build". Otherwise looks good (thanks for documenting). On Mon, Aug 13, 2018 at 3:26 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8208665 > >

Re: RFR [XS]: 8208744: remove unneeded -DUSE_MMAP settings for JDK native libs builds -was : RE: unneeded -DUSE_MMAP in JDK native libs builds

Looks good to me. On Fri, Aug 3, 2018 at 5:58 AM, Alan Bateman wrote: > > > On 03/08/2018 00:21, David Holmes wrote: > >> On 3/08/2018 4:59 PM, Baesken, Matthias wrote: >> >>> Thank you David , can the change be pushed , or do I need a second >>> review for an XS change ? >>> (any way a

Re: unneeded -DUSE_MMAP in JDK native libs builds

Yes, my recollection is that USE_MMAP was only ever used to control mmap actions in zip_util.[ch].

Re: RFR: Update build documentation to reflect compiler upgrades at Oracle

ersion relates to the official clang/llvm version, > it's most likely apple specific. But since that is how the compiler > identifies itself, I'm going to go with it. > > /Erik > > On 2018-07-23 10:20, Martin Buchholz wrote: > > + macOS Apple Xcode 9.4 (using clang

Re: RFR: Update build documentation to reflect compiler upgrades at Oracle

+ macOS Apple Xcode 9.4 (using clang 9.1.0) Is there really such a thing as clang 9.1.0, given that 6.0.1 is the latest from http://releases.llvm.org/ ? On Mon, Jul 23, 2018 at 10:13 AM, Erik Joelsson wrote: > The build documentation needs to be updated to reflect the compiler >

Re: adding additional numbers to the Java version string

OK. Despite our deep interest in version strings, we rarely use Runtime.Version. On Thu, Jul 19, 2018 at 12:42 PM, Tony Printezis wrote: > Hi Martin, > > Yes, we have also used the opt field too. However, if I understand the > spec correctly, when doing version comparisons, the opt string is

Re: adding additional numbers to the Java version string

At Google we use --with-version-opt to put in local version data - that works for us. --with-version-patch is also available for third party build use. On Thu, Jul 19, 2018 at 6:54 AM, Erik Joelsson wrote: > Since JEP 223 specifies an arbitrary length (something I had missed > before), I

Re: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH

Looks good to me! On Wed, Jun 27, 2018 at 3:26 AM, Volker Simonis wrote: > Hi, > > can I please have a review for the following tiny test fix (I'm > actually not sure which would be the appropriate mailing list for this > fix so please redirect if necessary): > >

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

Since the question of how to get the stack pointer in hotspot is unexpectedly difficult, I propose we split into two separate changes and we can submit the make/ changes that Erik is happy with.

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

I see stack pointers (and frame pointers) declared as intptr_t* which makes no sense to me. These are all "just" pointers, so declare them as either void* or intptr_t or address In the construct below, we could elide the cast if we had declared esp right in the first place?! intptr_t* esp;

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

There sure seems to be a lot of confusion about how many stack frames we're getting at the hot end of the stack, e.g. register intptr_t **fp __asm__ (SPELL_REG_FP); // fp is for this frame (_get_previous_fp). We want the fp for the // caller of os::current_frame*(), so go up two frames.

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

tüfe wrote: > On Fri, Jun 22, 2018 at 1:57 PM, David Holmes > wrote: > > On 21/06/2018 10:37 PM, Thomas Stüfe wrote: > >> > >> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes > >> wrote: > >>> > >>> On 21/06/2018 10:05 AM,

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

21, 2018 at 5:37 AM, Thomas Stüfe wrote: > On Thu, Jun 21, 2018 at 1:27 PM, David Holmes > wrote: > > On 21/06/2018 10:05 AM, Martin Buchholz wrote: > >> > >> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz >> <mailto:marti...@google.com>> wrote: >

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz wrote: > Hi David and build-dev folk, > > After way too much build/hotspot hacking, I have a better fix: > > clang inlined os::current_stack_pointer into its caller __in the same > translation unit___ (that could be fixed in a s

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

Thanks Erik. On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson wrote: > Hello, > > It's very probable that we have made several such mistakes with our flags, > since for the most part, we have a 1-1 mapping of compiler and OS. We > certainly appreciate correcting this whenever possible. I don't

clang and -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc

I saw in the *.cmdline files that when I build with clang, we get these defines: -DINCLUDE_SUFFIX_COMPILER=_gcc -DTARGET_COMPILER_gcc I see now that -DTARGET_COMPILER_gcc was intentional HOTSPOT_TOOLCHAIN_TYPE=$TOOLCHAIN_TYPE if test "x$TOOLCHAIN_TYPE" = xclang; then

THIS_FILE

While exploring the *.cmdline files created by the build (thank you, those are very helpful!) I noticed that they all contain -DTHIS_FILE='""' Probably there should be an actual file name there.

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

s indicates 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment() http://cr.openjdk.java.net/~martin/webrevs/jdk/clang-stack-alignment/ https://bugs.openjdk.java.net/browse/JDK-8186780 On Wed, Jun 20, 2018 at 12:30 AM, David Holmes wrote: > Hi Martin, > >

RFR: 8205197: Never default to using libc++ on Linux

8205197: Never default to using libc++ on Linux http://cr.openjdk.java.net/~martin/webrevs/jdk/stlib-default/ https://bugs.openjdk.java.net/browse/JDK-8205197

Re: build fail

https://bugs.openjdk.java.net/browse/JDK-8174050

Re: RFR: JDK-8200132: Remove jre images and bundles

JREs are a very long tradition. I suggest deferring disruptive changes like this to some release past jdk11. On Fri, Jun 1, 2018 at 3:02 PM, Erik Joelsson wrote: > Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing > much value. The idea is rather that you link together

RFR: 8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469

Hi Magnus, please review: 8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469 http://cr.openjdk.java.net/~martin/webrevs/jdk/ALSA_CFLAGS/ https://bugs.openjdk.java.net/browse/JDK-8201357

Re: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10

On Fri, Apr 6, 2018 at 2:50 AM, dalibor topic wrote: > > For example, if someone sufficiently qualified decided to make future JDK > 10 updates buildable using the full range of JDK 1.0 - JDK 10, as Martin > seemingly suggests, they could pursue that effort as future

Re: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10

On Wed, Apr 4, 2018 at 5:03 PM, David Holmes wrote: > On 5/04/2018 7:00 AM, Jonathan Gibbons wrote: > >> >> I have to agree. There can't be two bootJDK versions. I have to disagree. You could design openjdk to be buildable by any set of boot JDKs. It's only the fact

Re: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle

I presume build folk are aware that older compilers produce more portable binaries. My own rule of thumb is to use 5 year old compilers - battle tested, well aged, but haven't turned to vinegar yet. On Tue, Apr 3, 2018 at 11:14 AM, Erik Joelsson wrote: > This patch

Re: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10

I'm a big fan of portability and flexibility, so I would want to test with all the supported boot jdks, perhaps even chosen randomly. But if you test with only one boot jdk, then it should be the recommended version.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

On Tue, Apr 3, 2018 at 1:42 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > Here's an updated webrev that uses the same pattern as for native shared > libraries to hide non-exported symbols, for executables as well. > > I hope you're happy now :-) > > Thanks for your efforts! I

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On Tue, Apr 3, 2018 at 6:04 AM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > (pruning cc-list somewhat) > > On 2018-03-29 08:16, Martin Buchholz wrote: > > That surprises me. I'm quite certain that javah (or rather, java -h > nowadays) generate hea

Re: a.out left in root directory when configuring --with-toolchain-type=clang

point? > > /Magnus > > > On 2018-03-27 22:11, Erik Joelsson wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8200267 >> >> >> On 2018-03-27 12:35, Martin Buchholz wrote: >> >>> I notice that running bash ./configure ... leaves an a.ou

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2018-03-28 23:53, Martin Buchholz wrote: > > I can't find any documentation for what JNIEXPORT and friends actually do. > People including myself have been cargo-culting JNI

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

>From https://gcc.gnu.org/wiki/Visibility Why is the new C++ visibility support so useful? Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. This means: - *It very substantially improves load times of your DSO (Dynamic Shared

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > On 2018-03-28 22:39, Martin Buchholz wrote: > > > > On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie < > magnus.ihse.bur...@oracle.com> wrote: > >>

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

I can't find any documentation for what JNIEXPORT and friends actually do. People including myself have been cargo-culting JNIEXPORT and JNICALL for decades. Why aren't they in the JNI spec? --- It's fishy that the attribute externally_visible (which seems very interesting!) is ARM specific.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > Anyway, with this patch all symbols in executables will be visible, so > there should be no problem anyway. > The symbols visible in the main executable are a sort-of-public interface. The difference

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

I'm not sure about this. IIRC the AIX linker is able to use executables as a build-time input. Maybe our AIX maintainers have some expertise here. I think the _dynamic_ linker will see symbols in the executable. Resolving them is likely to be strictly more work at startup, and it is likely that

a.out left in root directory when configuring --with-toolchain-type=clang

I notice that running bash ./configure ... leaves an a.out file in the root directory of the jdk, but only after adding configure flags --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin (i.e. not when building with default gcc) Probably there's a test compilation whose

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

On Thu, Mar 22, 2018 at 8:13 AM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > > The interim JDK relies on javac and related tools being compilable by the > boot JDK. This imposes a restriction that the source code of those tools > must be conformant to the source version supported by

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

Now that we are releasing jdks an order of magnitude faster than before, we should reconsider the N-1 boot jdk policy. The primary beneficiaries of this are compiler-dev, who might like to code using the very features they are implementing. But for users, being able to bootstrap with an ancient

Re: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

On Thu, Mar 1, 2018 at 11:50 AM, Erik Joelsson wrote: > > On 2018-02-26 12:57, joe darcy wrote: > >> Hi Magnus, >> >> Looks okay for now, but longer term should the version be queried from >> the environment some way? >> >> The problem as I understand it is that the URL

Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

On Mon, Feb 26, 2018 at 4:31 PM, joe darcy wrote: > PS JDK 11 b02 bits now available for download: > > http://jdk.java.net/11/ Thanks, I am enjoying my jdk-11-ea+02 binaries. Consistent with the new model of a repo always at head (which is awesome) how about simply

Re: [urgent][jdk10] RFR: JDK-8198658 Docs still point to JDK 9 docs

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

Re: RFR: JDK-8198303 - jdk11+1 was build with incorrect GA date as 2018-03-20

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

Re: JDK10 build problem: "--module-path"?

Looking at https://packages.ubuntu.com/search?suite=all=all=any=openjdk-9-jdk=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, Feb 15, 2018 at 7:42 AM,

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

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

Re: "no tests selected" running tests in the test/jdk directory

dashes. On Mon, Feb 5, 2018 at 12:22 PM, Martin Buchholz <marti...@google.com> 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.

Re: "no tests selected" running tests in the test/jdk directory

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 >

"no tests selected" running tests in the test/jdk directory

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

Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

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

Re: OpenJDK installation instructions - SUSE install instructions are missing

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, isn't i

Re: OpenJDK installation instructions - SUSE install instructions are missing

[+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

Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

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 <marti...@google.com> wrote: > Differing projects have come to different conclusions about whether to

Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

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

Re: [PATCH] Fail to build zero on x86

[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

Re: bash configure fails on missing javah

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

Re: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

On Mon, Dec 18, 2017 at 3:50 PM, <mark.reinh...@oracle.com> wrote: > 2017/12/18 15:36:03 -0800, Martin Buchholz <marti...@google.com>: > > Mark, thanks for implementing my little feature request. Looks good to > me. > > I didn't know you'd requested this -- is the

Re: 10 RFR (XS) 8193764: Cannot set COMPANY_NAME when configuring a build

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:

  1   2   3   >