Jdk master freebsd diff #23611

snake66 · 2025-02-13T11:42:42Z

This is the cleaned up diff between the OpenJDK BSD port that has been maintained in separate repos up until now. It is meant primarily to give an overview of the scope and complexity of the changes, not necessarily as a patch to me merged as is in one go.

For this patch set I have rebased all the changes on top of the current jdk master branch, instead of keeping the original patches and commit history. Again, this if for assessing the scope of the changes, not necessarily how the changes will be submitted.

The actual changes in these patches are for the vast majority authored by @battleblow and @bsdkurt. I have just updated and cleaned them up to apply to the current jdk mainline branch.

The port builds and runs on FreeBSD x86_64, but I have not tested other cpu architectures yet. (Working on getting a build and test setup for aarch64 now.)

Some notes:

This brings back the DTrace support that was originally removed when Solaris and SPARC support was cleaned out in commit 071bd52.
There's quite a bit of duplication of code where the BSD port adds source files that are more or less exact copies of the linux equivalent. These could probably be moved to the unix platform directories instead. I have for the most part kept the duplicated variants in this patch set, updating them as needed to make the build pass.
My scope as I'm doing this work for The FreeBSD Foundation is only on FreeBSD. However the patch set includes a number of changes relevant for OpenBSD and NetBSD as well. (For some files even only for these OS's.) I have chosen to keep these, as I don't want to break the port for them, but I don't have the means or time to validate and test them. Hopefully @battleblow or @bsdkurt can help with that. In any case, feedback on how to deal with these platforms is most welcome!

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Error

⚠️ Found copyright format issue for oracle in [src/jdk.net/bsd/native/libextnet/BsdSocketOptions.c]

Warnings

⚠️ Patch contains a binary file (src/java.desktop/share/classes/java/awt/doc-files/BorderLayout-1.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/java/awt/doc-files/FlowLayout-1.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/java/awt/doc-files/GridBagLayout-1.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/java/awt/doc-files/GridBagLayout-2.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/java/awt/doc-files/GridLayout-1.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/java/awt/doc-files/GridLayout-2.gif)
⚠️ Patch contains a binary file (test/hotspot/jtreg/runtime/ClassFile/JsrRewritingTestCase.jar)
⚠️ Patch contains a binary file (test/hotspot/jtreg/runtime/ClassFile/testcase.jar)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23611/head:pull/23611
$ git checkout pull/23611

Update a local copy of the PR:
$ git checkout pull/23611
$ git pull https://git.openjdk.org/jdk.git pull/23611/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23611

View PR using the GUI difftool:
$ git pr show -t 23611

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23611.diff

This work is sponsored by The FreeBSD Foundation. Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

This merges the make and autoconf changes from the BSD port by glewis and bsdkurt on top of the OpenJDK mainline branch. This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

Sponsored by: The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

bridgekeeper · 2025-02-13T11:43:23Z

👋 Welcome back snake66! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-02-13T11:43:33Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-02-13T11:43:53Z

@snake66 this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout jdk-master-freebsd-diff
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

openjdk · 2025-02-13T11:44:11Z

@snake66 The following labels will be automatically applied to this pull request:

build
client
core-libs
graal
hotspot
i18n
jmx
net
nio
security
serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

dholmes-ora · 2025-02-14T03:58:56Z

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

@@ -9053,4 +9053,4 @@ DEFAULT_ATOMIC_OP(cmpxchg, 8, _seq_cst)

 #undef DEFAULT_ATOMIC_OP

-#endif // LINUX
+#endif // LINUX || _BSDONLY_SOURCE


You didn't update the ifdef on line 9026

dholmes-ora · 2025-02-14T04:01:48Z

src/hotspot/os/bsd/osThread_bsd.cpp

-#ifdef __APPLE__
+#ifdef _ALLBSD_SOURCE


This looks odd - does macOS define _ALLBSD_SOURCE?

Yes, _ALLBSD_SOURCE includes macOS. See https://github.com/openjdk/jdk/pull/23611/files#diff-d0d775e9532fd48537bb0e77eceed944df53747cb59143375f92d74710d0ea22L455-L457

But I have to admit I don't really like that myself.

Why is there even an ifdef for ALLBSD_SOURCE inside a file in the os/bsd directory? Afaik there are no instances where this could ever be undefined.

@magicus That looks like my mistake :)

Well, the original #ifdef __APPLE__ was weird too, since prior to the upcoming BSD port, bsd just means "macos" in Hotspot code, so it does not make sense as it currently looks in the mainline either...

dholmes-ora · 2025-02-14T04:07:15Z

src/hotspot/os/bsd/os_bsd.cpp

  static const arch_t arch_array[]={
    {EM_386,         EM_386,     ELFCLASS32, ELFDATA2LSB, (char*)"IA 32"},
    {EM_486,         EM_386,     ELFCLASS32, ELFDATA2LSB, (char*)"IA 32"},
    {EM_IA_64,       EM_IA_64,   ELFCLASS64, ELFDATA2LSB, (char*)"IA 64"},
    {EM_X86_64,      EM_X86_64,  ELFCLASS64, ELFDATA2LSB, (char*)"AMD 64"},
    {EM_PPC,         EM_PPC,     ELFCLASS32, ELFDATA2MSB, (char*)"Power PC 32"},
    {EM_PPC64,       EM_PPC64,   ELFCLASS64, ELFDATA2MSB, (char*)"Power PC 64"},
-    {EM_ARM,         EM_ARM,     ELFCLASS32,   ELFDATA2LSB, (char*)"ARM"},
+    {EM_ARM,         EM_ARM,     ELFCLASS32, ELFDATA2LSB, (char*)"ARM"},
+    {EM_AARCH64,     EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"},


Curious that this does not exist for macOS Aarch64 ... I wonder what it does for this code.

I don't know tbh, I'll look into it though. I'm starting to look at the arm code now.

prrace · 2025-02-14T04:59:49Z

src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h

@@ -11,8 +11,13 @@ extern "C" {

 #include <stdint.h>

-#if !defined(__FreeBSD__) && !defined(__MidnightBSD__) && !defined(AIX)


I realise that this is not an actual JDK PR so I've not looked at the other stuff, but this change to an imported file is dubious. You should help pipewire support BSD so this comes in ready-made.

Good point, I'll see what we can do about that.

As far as I understand , libpipewire was imported into OpenJDK for java.awt.Robot support for Wayland, the change was 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots
Have you looked into the Wayland support for BSD ? Probably 8280982 was done mostly with Linux in mind .

@MBaesken Thanks, that's a very useful pointer. I'll look into it. It may be that support for Wayland (and Pipewire) is not that important to us at this time. But I have to check around a bit about that.

emaste · 2025-02-18T17:36:02Z

make/autoconf/flags-ldflags.m4

-    # Add -z,defs, to forbid undefined symbols in object files.
-    # add -z,relro (mark relocations read only) for all libs
+    # Add -z defs, to forbid undefined symbols in object files.
+    if test "x$OPENJDK_TARGET_OS" != xbsd; then


Do we know what fails on FreeBSD?

@emaste Yes, it's gcc fails with a reference to undefined symbol environ linker error. The build completes with clang, though.

Oh, I remember running into that environ symbol issue long time ago, maybe on Solaris, or when I've been toying around with the BSD port myself. I think I tried to get to the bottom of it and figure out what was causing this, but I don't recall what I ended up with. Do you have any more information about what this is, and what would be the proper way to link? Ideally, we would not have to forgo -z defs, even on BSD.

@magicus The man page isn't too informative, but from what I've gathered, the symbol should be defined when the process is created and resolved by the dynamic loader when the library is loaded. Didn't follow it too deeply at the time, but I agree it's something to look at before proposing this upstream.

It seems environ is created by "csu" (whatever that is), and it is apparently a known nuisance when porting to FreeBSD: https://reviews.freebsd.org/D30842. (FWIW, reports on the net suggests NetBSD does not have this problem; I don't know about OpenBSD).

There are indications that something like -Wl,--ignore-unresolved-symbol -Wl,environ might work, but it is not clear to me exactly which linkers support this option.

So I guess this will be needed. But please add a comment about the environ symbol on BSD to explain why we are removing this (otherwise excellent!) check.

theRealAph · 2025-02-20T09:24:33Z

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp

  address addr = (address)uc->uc_mcontext.regs->gpr[ra] + (ssize_t)ds;
+#elif defined(_ALLBSD_SOURCE)
+  address addr = (address)uc->uc_mcontext.mc_gpr[ra] + (ssize_t)ds;
+#endif


As far as I can tell, this code dealing wih ucontext is unreachable.

Its only caller is

bool is_safepoint_poll() { // The current arguments of the instruction are not checked! if (USE_POLL_BIT_ONLY) { int encoding = SafepointMechanism::poll_bit(); return MacroAssembler::is_tdi(long_at(0), Assembler::traptoGreaterThanUnsigned | Assembler::traptoEqual, -1, encoding); } return MacroAssembler::is_load_from_polling_page(long_at(0), nullptr); }

magicus · 2025-02-20T16:05:37Z

make/data/charsetmapping/stdcs-bsd

@@ -0,0 +1,22 @@
+#


It is just silly that we have platform-specific versions of this file. I'll try to change the build so we can have a basic shared standard set, and only add additional platform-specific character sets where those are needed (AIX, I'm looking at you).

Actually, I seem to have misremembered the situation. I thought that we had one file per platform which were basically identical except for a few idiomatic changes. This turned out not to be the case. (It might have been so in the past and then been fixed.)

Instead, these files are not required. For instance, there is nostdcs-macosx. If they are present, they list additional charsets that should be included in java.base, as opposed to being included in jdk.charsets. (Basically, this is a way to keep down the size of the java.base module, but not trying to break too many real-world applications that might depend on more specific character sets).

Since there is no legacy BSD JDK distribution to support, I recommend you just leave out this file. That does not mean that these charsets are unavailable on BSD, just that you need the jdk.charsets module to access them. (At least, that is my understanding. @naotoj can probably correct me if I'm wrong.

Yes that's correct. Old Unix used to have default encodings other than UTF-8, such as SJIS in Japanese locale. In those situations, Java runtime will fail to start if the encoding (in this case, SJIS) is not in java.base module. However, recent OSes use UTF-8 as the login encoding, no need to have those legacy encodings additionally in java.base (that is why stdcs-macos does not exist)

@naotoj @magicus Thanks for the clarification. Currently the build complains if the file is not there, but that's probably something that can be fixed elsewhere. I'm making a note of this, and will look into it when I get to that part again.

magicus · 2025-02-27T17:04:57Z

make/hotspot/lib/JvmDtraceObjects.gmk

+    # object files from the libjvm compilation, so this generation must happen
+    # as a part of the libjvm compilation.
+
+    DTRACE_OBJ := $(JVM_OUTPUTDIR)/objs/dtrace.o


I just want to double-check before accepting this piece of necromancy -- is dtrace really used on BSD, in a way that this instrumentation is needed? There is some dtrace support already in the system, in the form of generated header files in make/hotspot/gensrc/GensrcDtrace.gmk. Maybe that is enough to achieve what you want?

(I will admit that I don't really understand what this dtrace instrumentation does, or how it differs from the generated code we still keep. What I do know is that this is kludgy from a built perspective, and I'd like to keep it in its grave, if possible.)

I pretty much have the same questions as you on this. I noticed it was removed with the Solaris and SPARC support some time ago, but don't really know the reason for bringing it back for BSD. Unless I get any convincing arguments otherwise, I'm planning to leave this out at least until later.

magicus · 2025-02-27T17:06:19Z

make/modules/java.instrument/Lib.gmk

@@ -31,17 +31,29 @@ include LibCommon.gmk
 ## Build libinstrument
 ################################################################################

+ifeq ($(call isTargetOs, bsd), true)


Once again, this is not how this works anymore. If you really need a static library, you need to change BUILD_LIBJLI_TYPE in make/modules/java.base/lib/CoreLibraries.gmk, as is done for AIX.

magicus · 2025-02-27T17:09:41Z

src/hotspot/os/bsd/globals_bsd.hpp

@@ -35,6 +35,12 @@
                         range,                                         \
                         constraint)                                    \
                                                                        \
+																		\


Tabs are not accepted in JDK source files; please replace them with space. I recommend looking at the tool expand.

magicus · 2025-02-27T17:14:50Z

src/hotspot/os_cpu/bsd_zero/javaThread_bsd_zero.cpp

@@ -1,6 +1,6 @@
 /*
 * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved.
- * Copyright 2009, 2010 Red Hat, Inc.
+ * Copyright (c) 2009, 2021, Red Hat, Inc. All rights reserved.


I don't think you should be touching Red Hat copyright lines like this..?

No, that's clearly wrong. Probably a result of comparing between master and jdk23u or jdk24u.

magicus · 2025-02-27T17:17:54Z

src/java.base/bsd/classes/sun/nio/ch/KQueueSelectorImpl.java

+import static sun.nio.ch.KQueue.EV_DELETE;
+
+/**
+ * KQueue based Selector implementation for macOS


This is pure copy/paste of macOS code?

If bsd and macos share the exactly same code, I think it is better to solve this in the makefiles, so the same code gets picked up by both macos and bsd builds.

Agreed!

As mentioned on the mailing list, I think there's more cases like this, but also between BSD and Linux.

magicus · 2025-02-27T17:24:45Z

src/java.base/unix/native/libnio/MappedMemoryUtils.c

@@ -43,6 +43,9 @@ typedef char mincore_vec_t;
 jboolean JNICALL MappedMemoryUtils_isLoaded0(JNIEnv *env, jobject obj, jlong address,
                                             jlong len, jlong numPages)
 {
+#ifdef __OpenBSD__
+    return JNI_FALSE;


Is this like a FIXME, or is this just not supported by OpenBSD? I am not well acquainted with MappedMemoryUtils, but it seem to me that if this is not suppored on OpenBSD, there would be more checks that disable the functionality?

Again, I don't really know. It's the port as I've received it, so I'm just posting it for the overview. It's good feedback though. I will have to look into more details when I get to that part, or even drop the specifics for Open/NetBSD for now.

magicus · 2025-02-27T17:26:05Z

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c

 #else
    throwUnixException(env, ENOTSUP);
 #endif

-    if (res == (size_t)-1)
+    if (res == (ssize_t)-1)


Is this casting really needed if you change type on res to ssize_t?

No, it should not be.

magicus · 2025-02-27T17:28:19Z

src/java.desktop/bsd/data/fontconfig/fontconfig.properties

-filename.AR_PL_ZenKai_Uni=/usr/share/fonts/chinese/TrueType/ukai.ttf
-filename.Baekmuk_Gulim=/usr/share/fonts/korean/TrueType/gulim.ttf
-filename.Baekmuk_Batang=/usr/share/fonts/korean/TrueType/batang.ttf
+## FIXME: Should not hardcode /usr/local


Is this FIXME going to be addressed for the initial port? (It looks like a much larger undertaking to move from the idea of having a set of properties with absolute paths, so I understand if you're not planning to do that. Especially if /usr/local is the de facto location on FreeBSD, as my understanding is)

I don't know yet, but most likely I'll focus on getting a port that works (for most cases) first, and deal with more special cases afterwards. It will of course also depend a bit on the feedback on the actual patches when I try to submit them :)

magicus · 2025-02-27T17:28:59Z

src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java

@@ -635,7 +635,8 @@ static void loadMotifDefaultColors(int[] systemColors) {


    static void loadSystemColors(int[] systemColors) {
-        if (OSInfo.getOSType() == OSInfo.OSType.LINUX) { // Load motif default colors on Linux.
+        if (OSInfo.getOSType() == OSInfo.OSType.LINUX
+            || OSInfo.getOSType() == OSInfo.OSType.BSD) { // Load motif default colors on Linux.


Update comment maybe? Or remove it, since it does not say anything that the code does not already say...

magicus · 2025-02-27T17:30:11Z

src/java.desktop/unix/native/libawt/java2d/j2d_md.h

@@ -28,11 +28,11 @@
 #include <sys/types.h>

 /*
- * Linux and MACOSX's version of <sys/types.h> does not define intptr_t
+ * Linux, MACOSX and BSD's version of <sys/types.h> does not define intptr_t


Suggested change

* Linux, MACOSX and BSD's version of <sys/types.h> does not define intptr_t

* Linux, macOS and BSD's version of <sys/types.h> does not define intptr_t

magicus · 2025-02-27T17:32:32Z

src/jdk.hotspot.agent/bsd/native/libsaproc/BsdDebuggerLocal.cpp

+#include "sun_jvm_hotspot_debugger_amd64_AMD64ThreadContext.h"
+#endif
+
+#if defined(sparc) || defined(sparcv9)


This seems outdated. Also, do you really support all these platforms on BSD?

In particular NetBSD is notorious for supporting all kinds of systems, but I'm not sure if we need to consider that for now at least. My focus is on FreeBSD, and mainly amd64 and aarch64. I'll probably leave anything outside of that for later.

magicus · 2025-02-27T17:35:01Z

src/jdk.hotspot.agent/bsd/native/libsaproc/dwarf.cpp

@@ -0,0 +1,329 @@
+/*


Is the Dwarf implementation really OS specific, or should we be able to generalize this across all operating systems that uses Dwarf data?

I was wondering the same, and I'm hoping it is not :) I'll look into it.

magicus · 2025-02-27T17:36:41Z

src/jdk.hotspot.agent/bsd/native/libsaproc/libproc.h

+#include <string.h>
+#include <fcntl.h>
+
+#ifdef __APPLE__


I don't think this makes sense. In contrast to the Hotspot code, the macOS build of the other native libraries in the JDK will not try to pick up files in a bsd directory.

Thanks, I'm making a note of it.

magicus · 2025-02-27T17:39:24Z

src/jdk.hotspot.agent/bsd/native/libsaproc/symtab.h

+
+#include <stdint.h>
+
+// interface to manage ELF or MachO symbol tables


MachO is not used on BSD, right? Seems like more copy/paste remnants from macOS.

That's probably correct. I'll check that.

snake66 · 2025-02-28T14:41:10Z

Thanks a lot for all the insightful comments so far!

It's a lot to go through, and I don't have all the answers yet, but I've got some good pointer on what to look at, and how to go about the project. Perhaps some of the most interesting feedback for me is where it would be better to not try to integrate what's in the existing BSD port, but rather look at it with fresh eyes based on the upstream code instead.

Not sure if you want me to keep this "PR" open for a bit more, in case there's other feedback that you think I should need? Or do you want me to close it so it don't cause too much noise in your PRs?

Again thanks!

magicus · 2025-03-03T21:47:48Z

Please keep it open. But you can mark it Draft so it is clear that it is for early review purposes, and not intended to be integrated.

magicus · 2025-03-13T09:33:59Z

Can you please merge (not rebase) an updated master into this PR when the iconv PR is integrated?

snake66 · 2025-03-13T11:45:53Z

Can you please merge (not rebase) an updated master into this PR when the iconv PR is integrated?

Sure, I will do!

This work is sponsored by The FreeBSD Foundation

snake66 · 2025-03-18T11:26:45Z

I have merged the current jdk master branch into this PR now for an updated view on the changes related to the BSD port.

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

magicus · 2025-03-20T13:17:36Z

make/autoconf/libraries.m4

@@ -200,20 +200,32 @@ AC_DEFUN_ONCE([LIB_SETUP_MISC_LIBS],
  # Setup posix pthread support
  if test "x$OPENJDK_TARGET_OS" != "xwindows"; then
    LIBPTHREAD="-lpthread"
+  elif test "x$OPENJDK_TARGET_OS" == "xbsd"; then


This will not work, the != windows will be selected for BSD, and this statement ignored.

@magicus You're of course right. I've since changes this in my branch, but not yet updated this PR.

magicus · 2025-03-20T13:21:17Z

make/modules/java.desktop/lib/ClientLibraries.gmk

@@ -67,8 +67,10 @@ ifeq ($(USE_EXTERNAL_LCMS), true)
  # If we're using an external library, we can't include our own SRC path
  # as includes, instead the system headers should be used.
  LIBLCMS_HEADERS_FROM_SRC := false
-  # FIXME: Keep old behavior and reset LCMS_CFLAGS. This is likely a bug.
-  LCMS_CFLAGS :=
+  ifeq ($(call isTargetOs, bsd), false)


This bug is being dealt with in #24131. Thanks for reminding me about it.

@magicus Yep, I saw that. I thought (hoped) that would be the proper fix, but didn't want to change anything for other platforms in this PR. :) I'll be merging in the remaining changes to the mainline, and update the PR within the week.

bridgekeeper · 2025-05-19T16:19:05Z

@snake66 This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

snake66 and others added 7 commits February 13, 2025 11:34

Set up confige and build for *BSD

7fa6f01

This work is sponsored by The FreeBSD Foundation. Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

Don't include alloca.h on BSD

2a60888

Sponsored by: The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

Add charset mapping for FreeBSD

3f7bec1

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

Move changes from BSD port to mainline

0c6c2e5

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

Bring back DTrace for BSD

7db66a7

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

Fix finding java home on BSD.

ecf8593

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Feb 13, 2025

dholmes-ora reviewed Feb 14, 2025

View reviewed changes

prrace reviewed Feb 14, 2025

View reviewed changes

emaste reviewed Feb 18, 2025

View reviewed changes

theRealAph reviewed Feb 20, 2025

View reviewed changes

magicus reviewed Feb 20, 2025

View reviewed changes

magicus reviewed Feb 27, 2025

View reviewed changes

snake66 marked this pull request as draft March 4, 2025 12:31

snake66 added 4 commits March 18, 2025 11:42

Merge branch 'master' into jdk-master-freebsd-diff

449a875

Fix include path for liblcms on BSD

90258d7

This work is sponsored by The FreeBSD Foundation

Fix missing FILE pointer in getPlatformTimeZoneID()

9db83d2

This work is sponsored by The FreeBSD Foundation

Update sun.tool.attach.VirtualMachineImpl for BSD

aa7a66b

This work is sponsored by The FreeBSD Foundation

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Mar 18, 2025

Use -pthread on bsd

9be139b

This work is sponsored by The FreeBSD Foundation Co-authored-by: Greg Lewis <[email protected]> Co-authored-by: Kurt Miller <[email protected]>

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Mar 19, 2025

magicus reviewed Mar 20, 2025

View reviewed changes

		@@ -11,8 +11,13 @@ extern "C" {

		#include <stdint.h>

		#if !defined(__FreeBSD__) && !defined(__MidnightBSD__) && !defined(AIX)

	* Linux, MACOSX and BSD's version of <sys/types.h> does not define intptr_t
	* Linux, macOS and BSD's version of <sys/types.h> does not define intptr_t


		#include <stdint.h>

		// interface to manage ELF or MachO symbol tables

		#ifdef __APPLE__
		#ifdef _ALLBSD_SOURCE

Jdk master freebsd diff #23611

Are you sure you want to change the base?

Jdk master freebsd diff #23611

Uh oh!

Conversation

snake66 commented Feb 13, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Error

Warnings

Reviewing

Uh oh!

bridgekeeper bot commented Feb 13, 2025

Uh oh!

openjdk bot commented Feb 13, 2025

Uh oh!

openjdk bot commented Feb 13, 2025

Uh oh!

openjdk bot commented Feb 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

snake66 commented Feb 13, 2025 •

edited by openjdk bot

Loading