On Wed, 15 Jun 2022 15:20:29 GMT, Magnus Ihse Bursie wrote:
> I accidentally changed the behavior in GHA wrt multiple runs from the same
> branch. The old solution used `cancel-in-progress: true` which means that an
> old batch was cancelled when a new commit was pushed to the branch.
>
> I th
On Tue, 5 Jul 2022 16:01:50 GMT, Magnus Ihse Bursie wrote:
> Since [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396), the flag `
> --enable-reproducible-build` is deprecated, and does nothing but print a
> warning. It is still included in the jib profiles, which make they output a
> w
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
I'm not very familiar with this, but it looks like clang/llvm does come
with its own strip utility, which would make this comment wrong.
On Linux, it's likely common to find the gnu binutils strip on the path
even when trying to use clang to compile OpenJDK. Ideally we should
setup STRIPFLAGS
On Tue, 26 Jul 2022 12:28:41 GMT, Aleksey Shipilev wrote:
> See the bug for symptoms and rationale.
>
> In short, after [JDK-8288396](https://bugs.openjdk.org/browse/JDK-8288396)
> moved the timestamp to `CFLAGS_VM_VERSION` macro, which changes with every
> build, we get Hotspot recompilation
Hello,
Building with --always-make seems like a bad idea and I would say not
recommended with the OpenJDK build. We try very hard to keep the
incremental build correct and reliable. While this particular problem
could be fixed, I wouldn't be surprised if there is more build logic
that relies
On Tue, 26 Jul 2022 19:53:10 GMT, Harold Seigel wrote:
>> Please review this fix for JDK-8285792. The fix removes print statements
>> from check_signal_handler() so that it doesn't print all the handlers every
>> time it finds one that is modified. Instead, it returns true if the handler
>>
On Wed, 27 Jul 2022 12:06:51 GMT, Weijun Wang wrote:
>> The DLL should be built no matter what `BUILD_CRYPTO` is.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> indentation change
Looks good.
Minor style nit. We like to h
On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters wrote:
> CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a
> defined, but empty macro in libjli if it is not defined in the build system,
> which is incorrect
Marked as reviewed by erikj (Reviewer).
-
PR: https:/
On 7/27/22 7:46 PM, Julian Waters wrote:
What would be a good way to test for the strip executable? The easiest
solution off the top of my head is to assume a particular compiler
uses a particular strip, but that sounds a little too inflexible.
Maybe assuming based on toolchain is good enough,
On Mon, 2 Oct 2023 10:31:41 GMT, Andrew Leonard wrote:
> When doing a reproducible Windows build on two different machines, that
> happen to have MS Visual Studio installed in different paths, the resulting
> builds are not identical. This is due to the System include paths, eg:
>
> C:\Program F
On Tue, 3 Oct 2023 08:58:25 GMT, Ludvig Janiuk wrote:
>> This pull request introduces changes in the build makefiles necessary to
>> enable the user to specify a jdk to use when launching jtreg. It introduces
>> a new configure flag, `--with-jtreg-jdk`, which takes a JDK path similar to
>> the
On 10/3/23 04:17, Frederic Thevenet wrote:
Hi David,
On 03/10/2023 04:49, David Holmes wrote:
Is there a reason we couldn't rename the dll's so that they do infact
have a prefix e..g libjava.dll? I would presume the linker
information would store the actual name.
Changing the names of the
On Wed, 4 Oct 2023 16:27:09 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on Windows using "--with-native-debug-info=external",
> the resulting debug symbols are saved in files located in the same folder as
> the corresponding executable or library and named by swapping the extension
On Mon, 2 Oct 2023 10:31:41 GMT, Andrew Leonard wrote:
> When doing a reproducible Windows build on two different machines, that
> happen to have MS Visual Studio installed in different paths, the resulting
> builds are not identical. This is due to the System include paths, eg:
>
> C:\Program F
On Thu, 5 Oct 2023 17:05:33 GMT, Mikael Vidstedt wrote:
> This change bumps the version of Xcode used for building at Oracle to Xcode
> 14.3.1 and updates the docs accordingly. The change also updates the devkit
> creation logic to work around issues with macOS.
Marked as reviewed by erikj (Re
On Fri, 6 Oct 2023 10:17:25 GMT, Andrew Leonard wrote:
> [JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
> -pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that
> are not dependent on the Visual Studio tooling install location. This however
> require
On Fri, 6 Oct 2023 13:01:03 GMT, Andrew Leonard wrote:
>> [JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
>> -pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that
>> are not dependent on the Visual Studio tooling install location. This
>> however req
On Fri, 6 Oct 2023 13:06:33 GMT, Andrew Leonard wrote:
>> [JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
>> -pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that
>> are not dependent on the Visual Studio tooling install location. This
>> however req
On Mon, 9 Oct 2023 09:21:06 GMT, Frederic Thevenet
wrote:
> I have added a basic test that verifies that symbols can be resolved by the
> internal jdk tooling that makes use of them, even after the name change for
> the .pdb files. It relies on the fact that on Windows/MSVC, native frames
> c
On Mon, 9 Oct 2023 09:03:08 GMT, Frederic Thevenet
wrote:
>> make/CreateJmods.gmk line 83:
>>
>>> 81: ifneq ($(CMDS_DIR), )
>>> 82: DEPS += $(call FindFiles, $(CMDS_DIR))
>>> 83: ifeq ($(call isTargetOs, windows)+$(SHIP_DEBUG_SYMBOLS), true+public)
>>
>> Suggestion:
>>
>> ifeq ($(call i
On Mon, 9 Oct 2023 12:53:18 GMT, Erik Joelsson wrote:
> > I have added a basic test that verifies that symbols can be resolved by the
> > internal jdk tooling that makes use of them, even after the name change for
> > the .pdb files. It relies on the fact that on Windows/M
On Mon, 9 Oct 2023 14:18:30 GMT, Frederic Thevenet
wrote:
> According to the GHA workflow, tier1 test are run with a jdk build using the
> following `configure` line, which doesn't set `--with-native-debug-symbols`:
>
> ```
> bash configure --with-conf-name=windows-x64 --with-debug-level=fastd
On Tue, 10 Oct 2023 14:42:37 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix jmh test
>> launch failures noted in https://bugs.openjdk.org/browse/JDK-8317802?
>>
>> jmh apparently relies on annotation processors during compilation of a
>> benchmark. W
On Tue, 10 Oct 2023 15:26:39 GMT, Frederic Thevenet
wrote:
> From what I can tell, the test fails because of an unrelated issue with the
> "test-prebuilt" target used to run the test by GHA.
>
> According to the logs for the failed test, path to the symbol folder
> "/d/a/jdk/jdk/bundles/symbo
On Tue, 10 Oct 2023 16:52:52 GMT, Frederic Thevenet
wrote:
> All that to say that it looks like there might be a bug in ` test-prebuilt`
> (which doesn't mean there couldn't be one GHA too, of course...)
>
> Apologies if I'm just shooting in the dark here, but at a cursory glance, I
> notice
On Tue, 10 Oct 2023 17:09:51 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix jmh test
>> launch failures noted in https://bugs.openjdk.org/browse/JDK-8317802?
>>
>> jmh apparently relies on annotation processors during compilation of a
>> benchmark. W
On Wed, 11 Oct 2023 17:49:14 GMT, Mikael Vidstedt wrote:
> macOS 10.x is no longer receiving updates - the most recent/last release was
> 10.15.7 back in July of 2022. It's time to bump the target macOS version
> (min/max) for macosx-x64. macOS 11.x is still receiving updates.
>
> This change
On Wed, 11 Oct 2023 17:28:12 GMT, Srinivas Vamsi Parasa
wrote:
>> The goal of this PR is to address the follow-up comments to the SIMD
>> accelerated sort PR (#14227) which implemented AVX512 intrinsics for
>> Arrays.sort() methods.
>> The proposed changes are:
>>
>> 1) Restriction of the AVX
On Wed, 11 Oct 2023 21:04:25 GMT, Srinivas Vamsi Parasa
wrote:
>> make/modules/java.base/Lib.gmk line 230:
>>
>>> 228: CFLAGS := $(CFLAGS_JDKLIB) $(LIBFFI_CFLAGS), \
>>> 229: LDFLAGS := $(LDFLAGS_JDKLIB) \
>>> 230: $(call SET_SHARED_LIBRARY_ORIGIN), \
>>
>> If you
On Wed, 11 Oct 2023 22:40:20 GMT, Sandhya Viswanathan
wrote:
>> I see now that this is an unrelated change. In that case please avoid
>> changing whitespace in unrelated files for this PR.
>
> @erikj79 This space was inadvertently added as part of
> (https://github.com/openjdk/jdk/pull/14227)
On Thu, 12 Oct 2023 19:25:13 GMT, Mikael Vidstedt wrote:
> In GHA, the versions of macOS (note: the version used for build/test, **not**
> the target macOS version we compile for) and Xcode are starting to show age.
> It's time to update to more modern versions.
>
> This change bumps the macOS
On Fri, 13 Oct 2023 09:49:48 GMT, Emanuel Peter wrote:
> @vnkozlov asked me to guard some debug AD file rules in `#ifdef ASSERT`.
> https://github.com/openjdk/jdk/pull/14785#discussion_r1349391130
>
> We discovered that the `ASSERT` and `PRODUCT` are not yet passed to ADLC, and
> hence they ar
On Fri, 13 Oct 2023 18:01:44 GMT, Mikael Vidstedt wrote:
>> macOS 10.x is no longer receiving updates - the most recent/last release was
>> 10.15.7 back in July of 2022. It's time to bump the target macOS version
>> (min/max) for macosx-x64. macOS 11.x is still receiving updates.
>>
>> This ch
On Mon, 16 Oct 2023 10:34:37 GMT, Emanuel Peter wrote:
>> @vnkozlov asked me to guard some debug AD file rules in `#ifdef ASSERT`.
>> https://github.com/openjdk/jdk/pull/14785#discussion_r1349391130
>>
>> We discovered that the `ASSERT` and `PRODUCT` are not yet passed to ADLC,
>> and hence th
When the configure support for VS 2017 was originally added, there were
still compilation errors when using it. We never got around to removing
that comment after getting the build working again until a later JDK
release.
/Erik
On 10/16/23 07:59, Andrew Leonard wrote:
Does anyone know why the
On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato wrote:
>> CLDR provides very few short names for time zones, such as PST/PDT. This
>> will typically end up substituting names from the COMPAT provider. Once the
>> COMPAT is removed, they will be displayed in the GMT format, i.e.,
>> GMT+XX:YY. Alt
On Wed, 18 Oct 2023 09:31:22 GMT, Daniel Jeliński wrote:
> hsdis-binutils.c doesn't use any functions from libiberty.h. This header is
> absent on Ubuntu (installed separately, and under a different path), so
> removing the include fixes the hsdis compilation on Ubuntu.
>
> Additionally, the s
On Wed, 18 Oct 2023 23:02:18 GMT, Mikael Vidstedt wrote:
> The linux-arm32 build generates a somewhat spectacular number of warnings,
> all for the same code - the offset_of macro in hotspot:
>
>
> src/hotspot/share/utilities/globalDefinitions_gcc.hpp:144:40: warning:
> requested alignment 16
On Thu, 19 Oct 2023 17:08:20 GMT, Aleksey Shipilev wrote:
> Simple fix to allow running `.jasm` tests directly, like we can do now with
> `.java` and `.sh` tests.
>
> Before the fix:
>
>
> % make images test TEST=runtime/clone/LocalClone.jasm
> Test selection 'runtime/clone/LocalClone.jasm',
On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon wrote:
> The Graal code base has
> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
> its module to `jdk.compiler.graal` as part of preparations for Project
> Galahad. Due to the way Java modules work, this
On Fri, 20 Oct 2023 14:25:30 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, [JDK-8317039](https://bugs.openjdk.org/browse/JDK-8317039)
> caused a regression. The `$(JAVA)` variable did not just contain a path,
> which was assumed by the patch, but also the necessary flags in
> `$(JAVA_FLAGS)`
On Fri, 20 Oct 2023 19:18:47 GMT, Matthew Donovan wrote:
> Hello,
>
> In this PR I removed NSS tests from the ProblemList and updated NssTest to
> use Sqlite databases. I also removed code in PKCS11Test.java that falls back
> to NSS libraries installed on the test system. The tests can still b
On Tue, 24 Oct 2023 02:22:39 GMT, Zixian Cai wrote:
>> Sometimes it's useful to have a Ubuntu-based chroot when you want to ensure
>> compatibility of your deployment target and/or have access to packages that
>> might not be in Debian upstream for some architectures.
>>
>> Ubuntu-based sysroo
On Tue, 24 Oct 2023 02:45:41 GMT, Zixian Cai wrote:
> Currently, code blocks under list items are rendered in a single line, which
> is difficult to read and copy.
> For example, see below from
> https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.ht
On Tue, 24 Oct 2023 10:29:32 GMT, Frederic Thevenet
wrote:
> This PR addresses OS detection not working properly when running
> test-prebuilt on MSYS2, which causes some Windows specific tests to misbehave
> or fail in Github Actions.
make/RunTestsPrebuilt.gmk line 162:
> 160: OPENJDK_TARG
On Tue, 24 Oct 2023 19:58:58 GMT, Matthew Donovan wrote:
>> Hello,
>>
>> In this PR I removed NSS tests from the ProblemList and updated NssTest to
>> use Sqlite databases. I also removed code in PKCS11Test.java that falls back
>> to NSS libraries installed on the test system. The tests can st
On Wed, 25 Oct 2023 08:46:52 GMT, Frederic Thevenet
wrote:
>> This PR addresses OS detection not working properly when running
>> test-prebuilt on MSYS2, which causes some Windows specific tests to
>> misbehave or fail in Github Actions.
>
> Frederic Thevenet has updated the pull request incre
On Tue, 24 Oct 2023 22:21:00 GMT, Magnus Ihse Bursie wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Added a test to verify that symbols are available
>
> You don't have to rebase, in fact, you should not reba
On Wed, 25 Oct 2023 13:07:18 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the extensi
On Wed, 25 Oct 2023 23:06:59 GMT, Jonathan Gibbons wrote:
> Please review an update to the way that `javadoc` handles the default legal
> notices when generating docs.
>
> Previously, the default notices were taken from the module's `legal`
> directory (`$JAVA_HOME/legal/jdk.javadoc`), but in
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote:
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
make/langtools/tools/javacserver/client/Client.java line 57:
> 55: private static final int CONNECTION_TIME
On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken wrote:
>> Increase javacserver connection timeout values and max retry attempts for
>> better make stability on some slower machines.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last re
On Mon, 30 Oct 2023 15:41:48 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> Tested configure with binutils-src.
>
> Thanks
This is a good idea, but to get it to work I think we need to re-order things
in `configure.ac`. `BPERF_SETUP_BUILD_JOBS` is currently quite late.
`LIB_SETUP_LIBR
On Fri, 4 Aug 2023 16:17:04 GMT, Thomas Stuefe wrote:
> See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and subsequent
> [discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html)
> back in 2022.
>
> On Arm, we can generate either arm- or thumb-code (`-marm`
On 10/30/23 10:05, Philip Race wrote:
It is possible to use Xcode 12 on macOS14.
Our internal build system manages to make this work.
Don't ask me for the details, because I don't know them very well.
Internally we use macOS 13.x and Xcode 14.3.1 to build JDK 22, and
macOS 12.x and Xcode 12.4
On Tue, 31 Oct 2023 06:39:55 GMT, Robbin Ehn wrote:
> I think you are correct, I tested on some more machines.
>
> On my vf2 dev board (4-core rv64) it do speed up sh configure, from 7:19 to
> 3:40. I see like 20 instances of cc1 instead 1, a bit to many :)
Adding the `-j` flag without a n
On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeliński wrote:
> hb-subset and hb-style APIs are not used and not exported by libfontmanger.
> We can cut the compilation time by not compiling the unused files.
>
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine.
> This is
On Thu, 2 Nov 2023 07:14:14 GMT, null wrote:
>> Build failure with GCC8.3.1
>>
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:
>> I
On Wed, 1 Nov 2023 19:58:07 GMT, Mandy Chung wrote:
> Tool modules can be created via `jmod --main-class` option such that
> `ModuleMainClass` attribute will be added in `module-info.class` and the
> module's main class can be launched via `java -m ` without
> specifying the name of the main c
found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>>
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> null has updated the pull request incrementally
On 11/2/23 22:18, 吴 国璋 wrote:
If OpenJDK requires en-us environment, then nothing needs to be
changed. Please ignore this thread.
I should clarify this a bit. We aren't against making the build work on
different locales, but most of us are unable to verify that it keeps
working on anything by
On 11/3/23 11:18, Alan Snyder wrote:
I followed the directions to use xcode-select. Was I supposed to
reconfigure after that? I don’t remember if I did that or just a make
clean.
If you change out the toolchain through xcode-select, then you
definitely need to reconfigure after. I would e
On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote:
> Consider a simple module, like:
>
> module test {}
>
>
> And compile it with JDK 22 and JDK 21 using:
> javac --release 21
>
> The results of the compilations will differ: when compiling with JDK 21, the
> mandated java.base dependency wi
On Thu, 26 Oct 2023 23:29:00 GMT, Jonathan Gibbons wrote:
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.inte
On Mon, 6 Nov 2023 23:00:39 GMT, Mikael Vidstedt wrote:
> Oracle is updating the version of Visual Studio for building the JDK on
> Windows to Visual Studio 2022 17.6.5.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16533#pullrequestreview-1
On Wed, 8 Nov 2023 13:24:21 GMT, Magnus Ihse Bursie wrote:
>> Oracle is updating the version of GCC for building the JDK on Linux to
>> 13.2.0.
>>
>> Apart from the "obvious" changes, I'll add some color to the CompileJvm.gmk
>> changes. In particular, I ran into two different types of new war
On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote:
> Consider a simple module, like:
>
> module test {}
>
>
> And compile it with JDK 22 and JDK 21 using:
> javac --release 21
>
> The results of the compilations will differ: when compiling with JDK 21, the
> mandated java.base dependency wi
On Wed, 8 Nov 2023 16:31:47 GMT, Magnus Ihse Bursie wrote:
>> Consider a simple module, like:
>>
>> module test {}
>>
>>
>> And compile it with JDK 22 and JDK 21 using:
>> javac --release 21
>>
>> The results of the compilations will differ: when compiling with JDK 21, the
>> mandated java.b
On Fri, 27 Oct 2023 11:35:54 GMT, Jan Lahoda wrote:
> Consider a simple module, like:
>
> module test {}
>
>
> And compile it with JDK 22 and JDK 21 using:
> javac --release 21
>
> The results of the compilations will differ: when compiling with JDK 21, the
> mandated java.base dependency wi
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
> Problem: There is syslookup file which expects the required symbols to be
> exported using the
On 11/14/23 17:58, Julian Waters wrote:
This question was brought up in
https://github.com/openjdk/jdk/pull/15096, the issue is that awt.dll
has historically tried to avoid depending on msvcp.dll, and as
https://github.com/openjdk/jdk/pull/15096#issuecomment-1796303631
points out, it is unclea
On Thu, 16 Nov 2023 16:41:05 GMT, Magnus Ihse Bursie wrote:
> Update the build documentation to reflect the fact that non-English locales
> are only supported on a "best effort" principle, and add instructions how to
> install the necessary language pack to Visual Studio.
doc/building.md line
On Thu, 16 Nov 2023 17:40:36 GMT, Magnus Ihse Bursie wrote:
> The contents of the build README has been poorly kept up to date in places.
> With the move to Github, the need to have markdown syntax that looks good on
> Github has become apparent. The entire document has been in need for a while
On Thu, 16 Nov 2023 17:09:25 GMT, Magnus Ihse Bursie wrote:
> From the bug report: Building.md file contains a number of HTTP links that
> would need to be converted to HTTPS in order for clicking on the links on the
> OpenJDK web site at https://openjdk.org/groups/build/doc/building.html to
>
On Thu, 16 Nov 2023 21:03:33 GMT, Mikael Vidstedt wrote:
>> The contents of the build README has been poorly kept up to date in places.
>> With the move to Github, the need to have markdown syntax that looks good on
>> Github has become apparent. The entire document has been in need for a while
On Fri, 17 Nov 2023 16:33:44 GMT, Magnus Ihse Bursie wrote:
>> The contents of the build README has been poorly kept up to date in places.
>> With the move to Github, the need to have markdown syntax that looks good on
>> Github has become apparent. The entire document has been in need for a wh
On Mon, 20 Nov 2023 14:34:51 GMT, Magnus Ihse Bursie wrote:
> Reflow the markdown in building.md so line lengths of 80 is respected,
> wherever possible.
>
> Note that is is correct that the building.html file is unchanged (and indeed
> a sign that only markdown line breaks have been modified
On Mon, 20 Nov 2023 15:08:22 GMT, Magnus Ihse Bursie wrote:
>> Update the build documentation to reflect the fact that non-English locales
>> are only supported on a "best effort" principle, and add instructions how to
>> install the necessary language pack to Visual Studio.
>
> Magnus Ihse Bur
On Tue, 21 Nov 2023 16:15:43 GMT, Kevin Rushforth wrote:
> I don't think we need to match a `/`, so I recommend either:
>
> 1. A single rule excluding `jdk*`, as in the current PR
> 2. A single rule excluding `jdk[0-9]*`
> 3. Two rules, one excluding `jdk[0-9]*` and a second excluding `jdk-*`
>
On Tue, 21 Nov 2023 18:16:35 GMT, Erik Joelsson wrote:
> > I don't think we need to match a `/`, so I recommend either:
> >
> > 1. A single rule excluding `jdk*`, as in the current PR
> > 2. A single rule excluding `jdk[0-9]*`
> > 3. Two rules, one excluding
On Thu, 23 Nov 2023 15:08:42 GMT, Magnus Ihse Bursie wrote:
> The OpenJDK build system does not support building when the source code
> resides on a path that contains a space. This requirement is documented in
> the build instructions but not enforced by the configure script.
>
> This change
On Mon, 27 Nov 2023 14:43:09 GMT, Magnus Ihse Bursie wrote:
> In theory, you can run "make install" on a newly built JDK to have it
> installed in /usr/local/bin, just as with many system tools.
>
> This is not recommended to do. You might mess up your boot JDK, and Java
> installations genera
On Mon, 27 Nov 2023 15:05:20 GMT, Magnus Ihse Bursie wrote:
>> For some reason, we have not been consistent with using spaces around the
>> assignment operators (`:=` and `=`) in spec.gmk.in. This has annoyed me for
>> a long time.
>>
>> When making this change, I noticed that there are a lot
On Mon, 27 Nov 2023 14:50:30 GMT, Magnus Ihse Bursie wrote:
> What's the issue with this? Full name on my profile "Galder Zamarreño".
I've dug into this a bit and here is what I've found. The letter
[`ñ`](https://www.compart.com/en/unicode/U+00F1#:~:text=%E2%80%9C%C3%B1%E2%80%9D%20U%2B00F1%20La
On Tue, 28 Nov 2023 10:17:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to workaround a bug
> in `dsymutil` tool on macos?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8320863, the `dsymutil` tool
> shipped in Xcode 14.3.1 has a bug which causes i
On Tue, 28 Nov 2023 14:29:25 GMT, Magnus Ihse Bursie wrote:
> To facilitate running make in the build configuration directory, we create a
> Makefile out of a template. Unfortunately, this references the real Makefile
> at $TOPDIR instead of $WORKSPACE_ROOT. They are normally equivalent, but if
On Tue, 28 Nov 2023 17:04:30 GMT, Magnus Ihse Bursie wrote:
> In quite a few places we are using the late evaluation assignment `=` instead
> of normal assignment `:=` in spec.gmk.in.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16859#pullr
On Tue, 28 Nov 2023 17:00:57 GMT, Magnus Ihse Bursie wrote:
> Over the year, even though we have tried to be diligent, there have been
> commits that modify files without updating the copyright year. Here is a mass
> update of the copyright years in the build system (`make/**`, `.github/**`).
This is a backout of
[JDK-8320863](https://bugs.openjdk.org/browse/JDK-8320863). That fix only works
on a very limited selection of Xcode versions, and is causing the build to fail
on other versions, including at least 12, 13 and 15.
-
Commit messages:
- Revert "8320863: dsymutil
On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote:
> Time to start making preparations for JDK 23.
Build changes look good.
-
Marked as reviewed by erikj (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1754115586
On Tue, 28 Nov 2023 21:48:13 GMT, Erik Joelsson wrote:
> This is a backout of
> [JDK-8320863](https://bugs.openjdk.org/browse/JDK-8320863). That fix only
> works on a very limited selection of Xcode versions, and is causing the build
> to fail on other versions, including at leas
On Wed, 29 Nov 2023 02:25:20 GMT, Mikael Vidstedt wrote:
> When building linux-aarch64 at Oracle using jib,
> --openjdk-target=aarch64-linux-gnu is always specified regardless of if
> building natively or cross compiling (on linux-x64). Among other things this
> has the (harmless) effect of tr
(moving this to a new thread)
On 11/29/23 02:23, Magnus Ihse Bursie wrote:
I'm not objecting to this patch, which is fine as it goes, but I think that the
real test for cross compiling isn't a different build and target platform, but
a different build and target sysroot. You're often building
On Mon, 27 Nov 2023 20:04:54 GMT, Erik Joelsson wrote:
> > What's the issue with this? Full name on my profile "Galder Zamarreño".
>
> I've dug into this a bit and here is what I've found. The letter
> [`ñ`](https://www.compart.com/en/unicode/U+00F1#:~:
On Thu, 30 Nov 2023 09:39:54 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change will attempts to workaround an
>> issue in dsymutil?
>>
>> The previous attempt to use `--reproducer Off` has shown that it fails to
>> build on some other Xcode versions other than 14.3.1. Users
On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie wrote:
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
> practi
On 12/6/23 04:18, Andrew Haley wrote:
On 11/29/23 14:31, erik.joels...@oracle.com wrote:
Perhaps what we need to do is separate the notion of needing a separate
BUILD_JDK from the notion of cross compiling.
Isn't that what --with-sysroot= usually means? In that case, you're
building against an
On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet
wrote:
> When building OpenJDK on the Windows platform, version information are
> embedded as compiled resources into every native library and executable,
> which typically contain version numbers, copyright information, product name
> and ve
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-development community edition.
>
> Cla
1 - 100 of 1255 matches
Mail list logo
