On Wed, 2 Dec 2020 22:04:17 GMT, Erik Joelsson wrote:
>> We are indeed missing the macos-version-min argument when linking
>> libjvm.dylib. This is a bug.
>
> Filed https://bugs.openjdk.java.net/browse/JDK-8257633
Thanks for taking care of those issues. To be clear, there is no real need to
The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and
supported three different Linux signal API's: sigset, signal and sigaction:
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
Only sigaction is a Posix supported API for multi-threaded
On Wed, 2 Dec 2020 22:48:41 GMT, Erik Joelsson wrote:
>> After fixing JDK-8256810 and starting to look into backporting it, I
>> discovered more potential failing cases. Certain versions of GCC may
>> sometimes output multiple prerequisite files on the same line. I think the
>> easiest way to
> After fixing JDK-8256810 and starting to look into backporting it, I
> discovered more potential failing cases. Certain versions of GCC may
> sometimes output multiple prerequisite files on the same line. I think the
> easiest way to handle this new issue is to split such lines.
>
> When
On Wed, 2 Dec 2020 18:54:17 GMT, Erik Joelsson wrote:
>> After fixing JDK-8256810 and starting to look into backporting it, I
>> discovered more potential failing cases. Certain versions of GCC may
>> sometimes output multiple prerequisite files on the same line. I think the
>> easiest way to
On Wed, 2 Dec 2020 21:41:26 GMT, Erik Joelsson wrote:
>> test/make/TestFixDepsFile.gmk line 60:
>>
>>> 58: $(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected
>>> 59: $(ECHO) " /foo/baz" >> $(DEPS_FILE).expected
>>> 60: $(DIFF) $(DEPS_FILE).expected
On Wed, 2 Dec 2020 22:00:55 GMT, Erik Joelsson wrote:
>> The current intention is to be consistent with the min system version and
>> it's currently set to 10.9. If libjvm.dylib gets a different value, then
>> that would be a bug, but note that this could also vary depending on how the
>>
On Wed, 2 Dec 2020 21:57:15 GMT, Erik Joelsson wrote:
>> Interesting, I still able to run the build after this change on macOS
>> 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm.
>> libjli, libjava have one, and it's 10.9
>
> The current intention is to be consistent
On Wed, 2 Dec 2020 21:32:46 GMT, Anton Kozlov wrote:
>> I wonder if we should be "upping" that to something later.
>> 10.9 is over 7 years old and has been out of support for what - 4 years ?
>
> Interesting, I still able to run the build after this change on macOS 10.9.5.
> I use jdk image and
On Wed, 2 Dec 2020 20:01:08 GMT, Tim Bell wrote:
>> Erik Joelsson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added test
>
> test/make/TestFixDepsFile.gmk line 60:
>
>> 58: $(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >>
On Wed, 2 Dec 2020 20:19:54 GMT, Phil Race wrote:
>> Unfortunately, no. AFAIK, the minimum target version is 10.9
>> https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I
>> had to keep indirection.
>
> I wonder if we should be "upping" that to something later.
> 10.9 is
> On Dec 2, 2020, at 12:22 PM, Phil Race wrote:
>
> On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote:
>
>>> Surely these days you can just call [NSProcessInfo operatingSystemVersion]
>>> directly ?
>>> If I read the doc below it is in the 10.10 SDK and later.
>>>
On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov wrote:
>> Surely these days you can just call [NSProcessInfo operatingSystemVersion]
>> directly ?
>> If I read the doc below it is in the 10.10 SDK and later.
>>
On Wed, 2 Dec 2020 17:55:18 GMT, Erik Joelsson wrote:
>> After fixing JDK-8256810 and starting to look into backporting it, I
>> discovered more potential failing cases. Certain versions of GCC may
>> sometimes output multiple prerequisite files on the same line. I think the
>> easiest way to
> After fixing JDK-8256810 and starting to look into backporting it, I
> discovered more potential failing cases. Certain versions of GCC may
> sometimes output multiple prerequisite files on the same line. I think the
> easiest way to handle this new issue is to split such lines.
>
> When
On Wed, 2 Dec 2020 17:41:54 GMT, Tim Bell wrote:
>> Erik Joelsson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make newline splitting work with BSD tar to make tests pass on macosx
>
> As @magicus wrote - this is subtle but looks
> After fixing JDK-8256810 and starting to look into backporting it, I
> discovered more potential failing cases. Certain versions of GCC may
> sometimes output multiple prerequisite files on the same line. I think the
> easiest way to handle this new issue is to split such lines.
>
> When
On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote:
> After fixing JDK-8256810 and starting to look into backporting it, I
> discovered more potential failing cases. Certain versions of GCC may
> sometimes output multiple prerequisite files on the same line. I think the
> easiest way to
On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote:
> After fixing JDK-8256810 and starting to look into backporting it, I
> discovered more potential failing cases. Certain versions of GCC may
> sometimes output multiple prerequisite files on the same line. I think the
> easiest way to
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote:
> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result
> that the legacy-jre-image builds a run-time image that contains the package
> and jlink tools. This seems to be an oversight as these tools should not be
>
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote:
> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result
> that the legacy-jre-image builds a run-time image that contains the package
> and jlink tools. This seems to be an oversight as these tools should not be
>
On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie wrote:
> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result
> that the legacy-jre-image builds a run-time image that contains the package
> and jlink tools. This seems to be an oversight as these tools should not be
>
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote:
> JDK-8251549 updated doc/building.md for building with git, but did not
> include corresponding updates to doc/building.html.
This pull request has now been integrated.
Changeset: e7ca0c4a
Author:Magnus Ihse Bursie
URL:
JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result that
the legacy-jre-image builds a run-time image that contains the package and
jlink tools. This seems to be an oversight as these tools should not be in the
equivalent of what we knew in the past as the "JRE".
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote:
> JDK-8251549 updated doc/building.md for building with git, but did not
> include corresponding updates to doc/building.html.
Looks good!
-
Marked as reviewed by shade (Reviewer).
PR:
On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie wrote:
> JDK-8251549 updated doc/building.md for building with git, but did not
> include corresponding updates to doc/building.html.
Marked as reviewed by sundar (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1557
JDK-8251549 updated doc/building.md for building with git, but did not include
corresponding updates to doc/building.html.
-
Commit messages:
- 8257224: JDK-8251549 didn't update building.html
Changes: https://git.openjdk.java.net/jdk/pull/1557/files
Webrev:
27 matches
Mail list logo
