On Thu, 17 Mar 2022 13:11:19 GMT, Julian Waters wrote:
> TOOLCHAIN_SETUP_MSVC_DLL always points to --with-msvcr-dll if it couldn't
> find the requested file, even if the dll being searched for was msvcp.dll for
> instance. This small patch fixes the potentially confusing advice to point to
> t
It was recently pointed out to me by Robbin Ehn that the build time for
exploded-image has undergone a major regression over the last two years.
I have conducted a series of performance tests starting with jdk-15+24,
and can confirm that sorry picture. :-( Despite certain individual gains
in b
On Fri, 18 Mar 2022 01:50:56 GMT, Ichiroh Takiguchi
wrote:
> This change is just for AIX platform with IBM XL C/C++ 16.1.
> By this change, lib's entry points are reduced by compilation and linkage
> option changes.
>
> Without changes:
>
> $ dump -X32_64 -Tv lib/libawt.so | grep EXP | wc
> 9
On Fri, 18 Mar 2022 08:03:11 GMT, Ichiroh Takiguchi
wrote:
>> This change is just for AIX platform with IBM XL C/C++ 16.1.
>> By this change, lib's entry points are reduced by compilation and linkage
>> option changes.
>>
>> Without changes:
>>
>> $ dump -X32_64 -Tv lib/libawt.so | grep EXP |
> 18 mars 2022 kl. 11:04 skrev Alan Bateman :
>
> I can't tell if you are planning to integrate this or wait until there is
> discussion on the locations proposed in the Informational JEP that you've
> just submitted. Maybe you plan to just integrate and then adjust/move again
> if needed?
I
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
&
On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote:
> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the
> https://openjdk.java.net/projects/riscv-port branch.
>
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
> Unmatched board. Da
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
d, even though this has nothing to do with the build. While
> this is annoying, a worse problem is if the actual team that needs to review
> the patch (i.e., the team owning the module) is missed in the review.
>
> ### Modules reviewed
>
> - [x] java.base
> - [x] java.desktop
&
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually
[JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference
linux machine. This was one of the four culprits that caused a 25-30% build
time regression over the last two years.
The problem here was that t
On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie wrote:
> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference
> linux machine. This was one of the four culprits that caused a 25-
On Wed, 23 Mar 2022 19:35:22 GMT, Phil Race wrote:
>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
>> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my
>> reference linux machine. This was one of the four culprits that caused a
>> 25-30% build time
ntal, and just seemed good at the time.
>
> This patch changes the optimization level to `SIZE` (which is the closest
> thing we have to no optimization level) on gcc.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last
On Wed, 23 Mar 2022 15:35:44 GMT, Erik Joelsson wrote:
> The version output of GNU time changed from "GNU time" to "GNU Time" in
> version 1.8. We need to update our check for identifying GNU time to handle
> this.
I usually handle cases like this by prefixing with a comment:
# Additional
On Wed, 23 Mar 2022 21:13:30 GMT, Magnus Ihse Bursie wrote:
>> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
>> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my
>> reference linux machine. This was one of the four culprits that
On Wed, 23 Mar 2022 22:37:55 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Restore HIGHEST for entire lib, just set SIZE to two files
>
> make/modules/java.
ntal, and just seemed good at the time.
>
> This patch changes the optimization level to `SIZE` (which is the closest
> thing we have to no optimization level) on gcc.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the
On Wed, 23 Mar 2022 23:38:52 GMT, Sergey Bylokhov wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update comment to show we don't care about these files.
>
> Do w
On Thu, 24 Mar 2022 07:38:34 GMT, Sergey Bylokhov wrote:
>>> @mrserb Phil said that we don't even use the subset part of harfbuzz.
>>>
>>> And unless you're backing up your claim that this patch is changing runtime
>>> characteristic with data, that's just a guess, just like the initial
>>> op
ated the pull request incrementally with one additional
> commit since the last revision:
>
> Update make/autoconf/basic_tools.m4
>
> Co-authored-by: Magnus Ihse Bursie
Marked as reviewed by ihse (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7925
On Wed, 23 Mar 2022 12:25:08 GMT, Magnus Ihse Bursie wrote:
> [JDK-8247872](https://bugs.openjdk.java.net/browse/JDK-8247872) (upgrade
> HarfBuzz to 2.7.2) caused build time to go up with 24 seconds on my reference
> linux machine. This was one of the four culprits that caused a 25-
On 2022-03-28 09:03, David Holmes wrote:
On 28/03/2022 4:56 pm, Alan Bateman wrote:
On 28/03/2022 07:46, David Holmes wrote:
Hi Jai,
It isn't obvious to me that the bundled sources are actually
intended to build on macOS. There's no include of unistd.h to get
the lseek definition.
I think th
On Sun, 27 Mar 2022 05:08:52 GMT, Mikael Vidstedt wrote:
> Oracle is updating the version of Visual Studio for building the JDK on
> Windows to Visual Studio 2022 17.1.0.
>
> This change adds support for building devkits based on VS 2022. Instead of
> creating a new script file for that I deci
On Mon, 28 Mar 2022 16:43:30 GMT, Mikael Vidstedt wrote:
>> Oracle is updating the version of Visual Studio for building the JDK on
>> Windows to Visual Studio 2022 17.1.0.
>>
>> This change adds support for building devkits based on VS 2022. Instead of
>> creating a new script file for that I
On 2022-03-29 03:42, Jaikiran Pai wrote:
Hello Magnus,
On 28/03/22 5:21 pm, Magnus Ihse Bursie wrote:
On 2022-03-28 09:03, David Holmes wrote:
On 28/03/2022 4:56 pm, Alan Bateman wrote:
On 28/03/2022 07:46, David Holmes wrote:
Hi Jai,
It isn't obvious to me that the bundled source
When a user has problems with their build environment that trips up their
builds, the cause is often one of just a few "popular" gotchas. For us working
with the build system, we've seen them all before, but for the individual user,
it's often the first time, and it can be really frustrating to
On Thu, 7 Apr 2022 07:53:38 GMT, Christoph Langer wrote:
> In GitHub Actions the step "Check that all tests executed successfully" will
> be marked as failing when the "Run tests" step did not run but some earlier
> step already failed. This is irritating and it can be corrected by doing the
>
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Thu, 7 Apr 2022 20:15:12 GMT, Erik Joelsson wrote:
>> @magicus
>> So I did think about this, and the alternative I think would be to hard code
>> a list of which object files are the output from assembly files, of which
>> there is about a dozen. Unless we could capture somehow the list of
On Fri, 8 Apr 2022 08:14:18 GMT, Magnus Ihse Bursie wrote:
>> It would certainly be possible to identify the objects created from assembly
>> source files based on file extensions, but it wouldn't help. The command
>> line would still be dependent on the current worki
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
@magicus thank you for looking at this, in hindsight I should have pinged you
to review this as well.
Technically Erik's approval is enough, but I do appreciate if I can get
at least 24h to have a look at build changes that touches delicate build
logic. It usually takes more than one of us t
On Fri, 8 Apr 2022 13:02:00 GMT, Erik Joelsson wrote:
>> Christian Hagedorn has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 60 commits:
>>
>> - Merge branch 'master' into JDK-8242181
>> - Fix build, add GCC flag gdwarf-4 to excl
On Wed, 6 Apr 2022 13:30:28 GMT, Andrew Leonard wrote:
>> This PR fixes the non-deterministic behavior when building on linux with
>> different userids or within
>> different workspace folders.
>> It fixes the following issues:
>> - MakeZipReproducible.java used to produce reproducible src.zip r
On Fri, 8 Apr 2022 14:10:05 GMT, Maxim Kartashev wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Trigger checks
>
> I did some experiments both with `gcc` and `clang`. Both respect the `.file`
> directive and pu
There's been unnecessary (near) duplication of functionality, and messy logic,
in the langtools gensrc step, for a long time. (Basically since we got rid of
the mercurial forest...)
This is a first attempt at cleaning this up. The file GensrcCommonLangtools.gmk
is removed. This contained three
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's r
On Fri, 8 Apr 2022 16:59:37 GMT, Erik Joelsson wrote:
>> There's been unnecessary (near) duplication of functionality, and messy
>> logic, in the langtools gensrc step, for a long time. (Basically since we
>> got rid of the mercurial forest...)
>>
>> This is a first attempt at cleaning this up
needed to be slightly
> modified to accept the same syntax as the JDK version of this tool.)
>
> A reasonable follow-up is to research if the two SetupCompileProperties tools
> can be unified into one.
Magnus Ihse Bursie has updated the pull request incrementally with one
On Fri, 8 Apr 2022 14:57:02 GMT, Magnus Ihse Bursie wrote:
> There's been unnecessary (near) duplication of functionality, and messy
> logic, in the langtools gensrc step, for a long time. (Basically since we got
> rid of the mercurial forest...)
>
> This is a first atte
On Fri, 8 Apr 2022 14:48:41 GMT, Andrew Leonard wrote:
>> I am not sure why without the explicit .file directive that the FILE symbol
>> in the ELF info contains an entry pointing to the .o object file, here's
>> what it was before:
>>
>> 31712: 0 FILELOCAL DEFAULT
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
On Tue, 12 Apr 2022 04:44:15 GMT, Daniel Jeliński wrote:
> This patch adds clickable link to commit messages in IntelliJ's git log.
> Example result:
> ![image](https://user-images.githubusercontent.com/30433125/162882312-6a9c7666-075d-47b7-9db5-22670b885e7b.png)
Clever idea.
-
Ma
On Sat, 9 Apr 2022 07:10:50 GMT, Christoph Langer wrote:
> Let's update some github actions versions. No really interesting or breaking
> changes but we should stay current.
Looks OK.
But there is really a LOT of redundancy in this file! :-( It is in desperate
need of some refactoring to keep
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
On Mon, 11 Apr 2022 15:41:20 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
I disagree completely. We had it this way in mainline originally, but it
was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393.
As you might know, I'm not too fond of the GHA solution, since we can't
debug issues with Github's hosts. Nevertheless, many users look at the
GHA results as
On 2022-04-13 05:39, Julian Waters wrote:
Recently I've been getting build failures on my Windows device that go
something along the lines of:
/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/.../x86_64-w64-mingw32/bin/ld.exe:
cannot find
d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-
On 2022-04-12 15:21, David Holmes wrote:
On Tue, 12 Apr 2022 11:31:03 GMT, Johannes Bechberger
wrote:
Adds an implementation of the missing method (guarded with `defined(AARCH64) &&
defined(__APPLE__)`) and fixes the compilation issues on Mac M1.
Looks good and trivial.
It seems apparent t
On Wed, 13 Apr 2022 11:30:14 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
tents though
You can modify make/scripts/fixpath.sh, and remove/comment out the line
rm -rf $TEMPDIRS
in the cleanup trap to keep it for post-mortem debugging.
/Magnus
best regards,
Julian
On Wed, Apr 13, 2022 at 7:04 PM Magnus Ihse Bursie
wrote:
On 2022-04-13 05:39, Julian Wat
On Thu, 14 Apr 2022 12:07:06 GMT, Andrew Leonard wrote:
>> This PR removes the need for relative object file linking introduced by
>> JDK-8284437 for linux libraries, by specifying
>> .file directives in the linux .S source files. The
>> source files specify a .file ASSEMBLY_SRC_FILE
>> where
On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote:
>> Found various typos of expected: `exepected`, `exept`, `epectedly`,
>> `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8284853: Fi
I ran `codespell` on the `make` directory, and accepted those changes where it
indeed discovered real typos.
(Due to false positives this can unfortunately not be run automatically)
Most of the fixes are in comments. A few are in messages aimed at the user.
-
Commit messages:
- 8
On Thu, 14 Apr 2022 16:05:48 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `make` directory, and accepted those changes where
> it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> Most of the fixes
JEP 298 was about removing demos and samples. Unfortunately,
[JDK-8173801](https://bugs.openjdk.java.net/browse/JDK-8173801) which should
have removed all files in src/samples, left a few non-source files (key stores
and images). These should be removed.
-
Commit messages:
- 82849
On Tue, 19 Apr 2022 08:47:18 GMT, Feilong Jiang wrote:
>> This patch adds Zero support for the 32-bit RISC-V architecture.
>>
>> Additional tests:
>>
>> - [x] Linux zero RISCV32 cross-compilation
>> - [x] Resulting binaries run on QEMU User mode without problems
>
> Feilong Jiang has updated th
On Thu, 14 Apr 2022 16:13:59 GMT, Andrew Leonard wrote:
> JDK-8282769 added support for more ISO-8601 formats, but remove handling of
> just a date "-MM-DD" being present, which is the case for a configure
> using --with-source-date=version which uses the date string from
> version-numbers
On Fri, 15 Apr 2022 11:49:29 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Could I get the following PR review please? It adds a new JDK specific
>> extended socket option
>> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
>> and IPv6
>> UDP sockets (NIO DatagramChannels
On 2022-04-14 19:42, Andrew Hughes wrote:
On 12:57 Wed 13 Apr , Magnus Ihse Bursie wrote:
I disagree completely. We had it this way in mainline originally, but it
was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393.
Prior to this patch, it seems there were no GCC version
On Tue, 19 Apr 2022 10:41:07 GMT, Magnus Ihse Bursie wrote:
> JEP 298 was about removing demos and samples. Unfortunately,
> [JDK-8173801](https://bugs.openjdk.java.net/browse/JDK-8173801) which should
> have removed all files in src/samples, left a few non-source files (key
>
Analogous to `UTIL_ARG_ENABLE`, we need a `UTIL_ARG_WITH` which wraps
´AC_ARG_WITH`, provides a declarative rather than programmatic way of handling
configure arguments. It can also make sure that all edge cases are covered, and
that we treat arguments consistently.
This PR contains the implem
On Tue, 19 Apr 2022 20:38:31 GMT, Magnus Ihse Bursie wrote:
> Analogous to `UTIL_ARG_ENABLE`, we need a `UTIL_ARG_WITH` which wraps
> ´AC_ARG_WITH`, provides a declarative rather than programmatic way of
> handling configure arguments. It can also make sure that all edge cases are
On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato wrote:
> Fixing performance regression caused by the fix to
> https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra
> looping through the resource map multiple times which was not necessary. The
> execution time of the tool now
A debug printout in configure was introduced in JDK-8285093. It should be
removed.
-
Commit messages:
- 8285919: Remove debug printout from JDK-8285093
Changes: https://git.openjdk.java.net/jdk/pull/8467/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8467&range=00
I
On Fri, 29 Apr 2022 12:43:02 GMT, Magnus Ihse Bursie wrote:
> A debug printout in configure was introduced in JDK-8285093. It should be
> removed.
This pull request has now been integrated.
Changeset: 64225e19
Author:Magnus Ihse Bursie
URL:
https://git.openjdk.java.net/jdk/
On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote:
> During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java
> heap is chosen by the OS. Due to Address Space Layout Randomization, the heap
> will always start at a different location. This causes the archive for
> uncompressed
On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote:
>> Currently we set _WIN32_WINNT at various places in the codebase; this is
>> used to target a minimum Windows version we want to support. See also for
>> more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/win
eproducible including the command-line
tools, demos, API documentation, JMOD archives, native libraries, and
man pages -- even when using a different build path. Note that I didn't
test on macOS or Windows.
A big thank you to Magnus Ihse Bursie and Andrew Leonard for doing much
of the work to
On Tue, 10 May 2022 01:36:06 GMT, David Holmes wrote:
>> The way LauncherCommon.gmk is currently written, it's only meant to be
>> included from "make/module//Launcher.gmk", or at least only from one
>> single place for each module. This is because the man page generation that
>> happens in La
On Mon, 9 May 2022 23:18:47 GMT, Erik Joelsson wrote:
> The way LauncherCommon.gmk is currently written, it's only meant to be
> included from "make/module//Launcher.gmk", or at least only from one
> single place for each module. This is because the man page generation that
> happens in Launch
On Tue, 10 May 2022 08:46:44 GMT, Severin Gehwolf wrote:
>> `make test TEST="gtest:> `1.10.0`. It expects `suites` to be present in the google test output
>> whereas the OpenJDK build infra code expects `cases`. I'm not sure when/if
>> that changed, but here is a proposed fix.
>>
>> Thoughts?
On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>> *
On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which fixes build failures on macos
> when using `--with-zlib=bundled`?
>
> With this change the build now passes (tested both with bundled and system
> zlib variants).
>
> tier1, tier2 and tier3
On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote:
>> Please review this patch adding new lint option, **lossy-conversions**, to
>> javac to warn about type casts in compound assignments with possible lossy
>> conversions.
>>
>> The new lint warning is shown if the type of the right-hand ope
On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin wrote:
>> make/modules/jdk.jfr/Java.gmk line 26:
>>
>>> 24: #
>>> 25:
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>>
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the
>> `lossy-conversions` warning should not be disabl
On 2022-05-11 16:01, Kim Barrett wrote:
Globally disabling use-after-free warnings for this package seems really
questionable. If these are problems in the code, just suppressing the warning
and leaving the problems to bite us seems like a bad idea. And the problems
ought to be reported upstream
On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - copyright years
>> - disable format-nonliteral warning when building LIBSPLASHSCREEN with
>> bundled zlib
>> -
On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which fixes build failures on macos
>> when using `--with-zlib=bundled`?
>>
>> With this change the build now passes (tested both with bundled and system
>> zlib variants).
>>
>> tier1, tier2 and
On Wed, 11 May 2022 19:14:54 GMT, Lance Andersen wrote:
>> make/autoconf/lib-bundled.m4 line 220:
>>
>>> 218: if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
>>> 219: LIBZ_CFLAGS="$LIBZ_CFLAGS
>>> -I$TOPDIR/src/java.base/share/native/libzip/zlib"
>>> 220: if test "x$OPENJDK_TARGET_OS"
(cc:ing build-dev.)
On 2022-05-12 00:17, Michael Hall wrote:
Is this restricted somehow to Mac App Store applications?
Is a warning issued as stripping native commands may break application
functionality?
Is it not possible for the user to provide their own Info.plist with a
different bund
On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change to the build system which now makes
> bundled zlib as the default for macos aarch64 systems?
>
> We have been running into various intermittent failures on macos aarch64
> systems for several mont
On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Calculate char offset before realloc()
>
> Thanks for all to review this PR! I think we should separate this is
On 2022-05-12 13:17, Michael Hall wrote:
I had read this but possibly didn’t grok the issue myself. If I
understand correctly now the conflict isn’t within the application but
across applications to some other application that has already been
added to the Mac App Store that included the comman
Aren't we embedding this bundle ID in every launcher, so you would
need a .template for each possible launcher that could be
included in an app?
I naively assumed that only the java launcher was needed, since this is
about packaging a Java app, so all you'd need is an entry to your main
clas
On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev
wrote:
>> - It is not possible to support native JDK commands such as "java" inside
>> Mac App Store bundles due to embedded info.plist. Workarounds suggested in
>> JDK-8286122 does not seems to be visible.
>> - With proposed fix we will enf
On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x
On Fri, 13 May 2022 08:43:35 GMT, Christian Hagedorn
wrote:
>> I'm googling around for some information about -gdwarf-4 but is mostly
>> coming up empty handed. :( I found
>> [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default)
>> saying that dwarf-5 bec
On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote:
> Please review this cleanup of deprecation warning suppression when building
> for Windows.
>
> This change consists of several parts.
>
> (1) Remove the global deprecation warning suppression when building HotSpot
> for Windows.
>
> (2) Ad
On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote:
> On AArch64 it is sometimes convenient to have LSE atomics right from the
> start. Currently they are enabled after feature detection and RR reverse
> debugger works incorrectly.
>
> New build configuration feature 'hardlse' is added. If
On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov wrote:
> Replaces usages of articles that follow each other in all combinations:
> a/the, an?/an?, the/the…
>
> It's the last issue in the series, and it still touches different areas of
> the code.
Build changes look good. Thanks for the cleanu
Testing ispell + shell magic to locate typos. It worked, but is not scalable to
the entire JDK. :-( Keep the fixes for the problems found in the make
directory, though.
-
Commit messages:
- 8287155: Additional make typos
Changes: https://git.openjdk.java.net/jdk/pull/8837/files
W
We have a bunch of configure arguments that has been deprecated for multiple
releases. These should be removed. In effect, this will raise an error instead
of a warning if these argument is included on the command line for configure.
The deprecated arguments stopped having any effect when they w
On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote:
> Testing ispell + shell magic to locate typos. It worked, but is not scalable
> to the entire JDK. :-( Keep the fixes for the problems found in the make
> directory, though.
This pull request has now been integrated.
On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote:
> We have a bunch of configure arguments that has been deprecated for multiple
> releases. These should be removed. In effect, this will raise an error
> instead of a warning if these argument is included on the command
On Tue, 24 May 2022 06:41:52 GMT, Christoph Langer wrote:
> It seems that it was forgotten to add the macOS aarch64 platform to the
> default platforms of workflow_dispatch. Let's fix this.
Marked as reviewed by ihse (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/8861
601 - 700 of 3318 matches
Mail list logo