On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern wrote:
> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang
> pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search
> librari
On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou wrote:
>> Please review the test fix that removes `libVThreadEventTest` explicit
>> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
>> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
>> the ch
On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern wrote:
> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang
> pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search
> librari
On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern wrote:
> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang
> pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search
> librari
On Wed, 5 Mar 2025 22:59:06 GMT, Jiangli Zhou wrote:
> Please review this PR that excludes `libjsig` from being statically linked
> with `static-jdk` `java` launcher by default. Please see details in
> https://bugs.openjdk.org/browse/JDK-8351309 description and comments. Thanks
To me this feel
With
[JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang pollutes
the burned-in library search paths of the generated executables
an ugly workaround was introduced to get rid of the unwanted list of search
libraries the clang compiler automatically burns into the executable fil
On Fri, 7 Mar 2025 09:28:15 GMT, Joachim Kern wrote:
> With
> [JDK-8348663](https://bugs.openjdk.org/browse/JDK-8348663) [AIX] clang
> pollutes the burned-in library search paths of the generated executables
> an ugly workaround was introduced to get rid of the unwanted list of search
> librari
On Fri, 7 Mar 2025 15:11:09 GMT, Magnus Ihse Bursie wrote:
> So, Daniel pointed out some irrelevant changes that you tried to sneak in. :)
> I think he is right that these should be reverted. I don't see anyone
> complaining about removing `-Zc:wchar_t-` though, or the necessary follow-up
> fi
On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou wrote:
>> Please review the test fix that removes `libVThreadEventTest` explicit
>> dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in
>> `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With
>> the ch
On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote:
> This PR implements JEP 503: Remove the 32-bit x86 Port.
>
> The JEP is proposed to target 25, we would not integrate until JEP is ready.
> Reviews are appreciated meanwhile.
>
> This is only the removal of obvious 32-bit x86 parts, mos
On Fri, 7 Mar 2025 07:21:43 GMT, David Holmes wrote:
>> It's no that important, no. I'm not sure if previous deprecated ports were
>> handles exactly like this.
>>
>> And you can always do like `git log | grep -i "remove .* port"` to find the
>> change it was removed in, and look what it did.
On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters wrote:
>> Was: sunmscapi.dll cannot compile with Visual C++
>>
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a
>> distinct C++ type when compiling with Visual C++ so jchar and wchar_t are
>> typedef'd to shorts on Windows
On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters wrote:
>> Was: sunmscapi.dll cannot compile with Visual C++
>>
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a
>> distinct C++ type when compiling with Visual C++ so jchar and wchar_t are
>> typedef'd to shorts on Windows
On Sat, 11 Mar 2023 16:07:54 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> AccessBridgeJavaEntryPoints.cpp
>
> Oops, didn't mean to do that. Oh well, will update this again later
@TheShermanT
Hi,
The dependencies required to build JDK vary depending on which JDK version
you are building. I've been building my own set of scripts that allows me
to easily manage this, to the extent that I can do it on the given base OS
I run. E.g. if I'm building a mainline I'd use X as boot JDK but if I'
Yeah we could mention, though I'm not sure what exactly we should say
there. I've only experimented with this on mac so far, but I hope to expand
to linux, in which case I'll see if I can take advantage of the existing
package definition somehow.
Also, you might notice some strange things in my sh
Hi Frederic,
I think your proposal makes sense, and as Erik says, the patch is very
unobtrusive.
I'm not at all sure if it is even possible, but if the signing logic for
macOS and Windows can be sort of unified and made more abstract, that
would certainly be a win.
/Magnus
On 2025-02-26
On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou wrote:
> I meant more like "not supported". You are correct that it is technically
> possible.
>
> How useful is signal chaining even these days?
>
It is a niche solution to a complex problem (using signals in third-party
native libraries which d
On Thu, 6 Mar 2025 18:57:48 GMT, Henry Jen wrote:
> IIUC, signal chaining is a link time question for native executable using
> hotspot(launchers), the `java` launcher in regular JDK build is disabled by
> default unless user preload the libjsig.
>
> So, for the future jmod to support static l
On Fri, 7 Mar 2025 12:00:24 GMT, Magnus Ihse Bursie wrote:
>> Oops, didn't mean to do that. Oh well, will update this again later
>
> @TheShermanTanker This seems like a good fix to make VSC++ behave according
> to standard. I think it should be resurrected.
@magicus I think this was closed by
Thank you for your report!
I have only touched nix briefly, but it's good to know that they seem to
have an official jdk package. Maybe we should mention this in the build
readme as an alternative way to setup a dev environment for the JDK?
/Magnus
On 2025-03-07 14:29, Galder Zamarreno wrote
On Thu, 6 Mar 2025 01:40:43 GMT, SendaoYan wrote:
>> Marked as reviewed by erikj (Reviewer).
>
> Thanks @erikj79 for the reviews and suggestions.
@sendaoYan I missed commenting on this before it was integrated, but should not
these disabled tests be counted under the new "SKIPPED" heading inst
On Tue, 4 Mar 2025 16:52:16 GMT, Aleksey Shipilev wrote:
> This PR implements JEP 503: Remove the 32-bit x86 Port.
>
> The JEP is proposed to target 25, we would not integrate until JEP is ready.
> Reviews are appreciated meanwhile.
>
> This is only the removal of obvious 32-bit x86 parts, mos
On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote:
>>> What is the intended way of using this? Do you run make with
>>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the
>>> specific way of linking to pthread?
>>
>> This is in preparation of the upcoming BSD port, which use
On Thu, 6 Mar 2025 19:22:23 GMT, Jiangli Zhou wrote:
> How useful is signal chaining even these days?
@magicus as useful as it has ever been if your application uses signals that
overlap with JVM usage.
-
PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705751155
This question belongs on build-dev. I've cc:ed that list, please keep
future discussions there and not in jdk-dev. I'll repsond to your
question in build-dev.
/Magnus
On 2025-03-07 16:28, Harald Eilertsen wrote:
Hi,
I've made a small patch to parameterize how support for pthreads is
enables
On Thu, 6 Mar 2025 21:45:29 GMT, Jiangli Zhou wrote:
> Let's check with @dougxc and others from GraalVM side
@wirthi or someone from the Native Image team will comment on this. Thanks for
the heads up.
-
PR Comment: https://git.openjdk.org/jdk/pull/23924#issuecomment-2705943175
On Fri, 7 Mar 2025 09:44:38 GMT, Thomas Stuefe wrote:
>>> I meant more like "not supported". You are correct that it is technically
>>> possible.
>>>
>>> How useful is signal chaining even these days?
>>>
>>> While we could do something like this, I see more trouble ahead. How should
>>> we d
On Fri, 7 Mar 2025 07:41:42 GMT, David Holmes wrote:
> > libjsig is provided by JDK.
>
> Yes for an application to chose to use so that its own signal usage can be
> better integrated with that of the JDK. Statically linking libjsig with a JDK
> makes no sense to me at all.
@dholmes-ora Pleas
On 2025-03-07 18:35, Magnus Ihse Bursie wrote:
This question belongs on build-dev. I've cc:ed that list, please keep
future discussions there and not in jdk-dev. I'll repsond to your
question in build-dev.
/Magnus
On 2025-03-07 16:28, Harald Eilertsen wrote:
Hi,
I've made a small patch to
Background (from JBS):
Recent versions of Xcode, most likely starting with Xcode 15, do not produce
deterministic binaries/libraries out of the box. In particular, the UUID data
in the LC_UUID load command is not stable.
After spending some significant time trying to understand why, it turns ou
31 matches
Mail list logo
