On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie 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?
>
>> What is the intended way of using this? Do you run ma
On Thu, 6 Mar 2025 09:48:47 GMT, Aleksey Shipilev wrote:
> After this PR integrates, it is not possible to build x86_32
You could add a couple of lines to the build code and it would not be possible
to build 32-bit, so that is a necessary but not sufficient condition to claim
to implement the
On Thu, 6 Mar 2025 18:23:24 GMT, Magnus Ihse Bursie wrote:
>> I don't mind removing it, my concern would be to _remember_ this option was
>> there! I guess it is okay to re-re-invent it later, possibly under a
>> different name, when the next port gets deprecated.
>
> It's no that important, no
On Thu, 6 Mar 2025 17:42:04 GMT, Jiangli Zhou 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.
> TestPosixSig.java failure
On Thu, 6 Mar 2025 00:16:12 GMT, Vladimir Ivanov wrote:
>> There's a wide variety of options to justify the goal of the JEP. A bare
>> minimum would be to just remove x86-32 build support. And on the other side
>> of the spectrum the current patch would be accompanied by all
>> x86-32-specific
On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote:
> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's
> possible to parameterize this for platforms that use different flags for
> enabling posix threads.
>
> This work is a continuation of the work done by Greg Lewis in
On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote:
> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's
> possible to parameterize this for platforms that use different flags for
> enabling posix threads.
>
> This work is a continuation of the work done by Greg Lewis in
Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's
possible to parameterize this for platforms that use different flags for
enabling posix threads.
This work is a continuation of the work done by Greg Lewis in [1], but
generalized for the full JDK, and set at the conf
On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann wrote:
> Add an .editorconfig to define indentation, trim trailing whitespace and open
> curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.
Attempts at introducing any kind of co
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
I am a bit conf
On Thu, 6 Mar 2025 16:01:16 GMT, Magnus Ihse Bursie wrote:
> This is not the correct way to solve this. You should flag libjsig as
> `ONLY_EXPORTED` instead, which means that the library will not be included in
> a static build.
I think we do want to include `libjsig.a` as part of the JDK stat
On Thu, 6 Mar 2025 12:37:52 GMT, David Holmes wrote:
> I am a bit confused here. libjsig is an application/end-user library.
libjsig is provided by JDK.
> It sounds like something is statically linking libjsig and causing signal
> chaining to break. ???
AFAICT, signal chaining works when lib
On Thu, 6 Mar 2025 18:49:54 GMT, Magnus Ihse Bursie 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 do when we
On Thu, 6 Mar 2025 20:20:59 GMT, Magnus Ihse Bursie wrote:
> It seems we agree that we need, at some point, to have a high-level
> discussion on if libjsig should be supported on static builds, and if so, how
> it should be implemented. We also agree that having signal chaining enabled
> by de
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
I filed https:/
On Wed, 19 Feb 2025 12:27:58 GMT, David Linus Briemann wrote:
> Add an .editorconfig to define indentation, trim trailing whitespace and open
> curly brace position for C++ and Java.
> This allows various editors to easily infer basics of the coding style.
I think a .editorconfig file is a good
On Thu, 6 Mar 2025 16:18:50 GMT, Magnus Ihse Bursie 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 pa
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
I meant more li
On Thu, 6 Mar 2025 05:55:48 GMT, Man Cao wrote:
> libjsig is not supposed to be enabled by default. Per [Java 23
> doc](https://docs.oracle.com/en/java/javase/23/troubleshoot/handle-signals-and-exceptions.html#GUID-CB49A2A7-2A9F-4C18-948F-6D4A96FF688D),
> it is user's choice whether to use libj
On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by G
On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson 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 uses `-pthread
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 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
This is not the
On Thu, 6 Mar 2025 15:56:43 GMT, Magnus Ihse Bursie wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done
On Thu, 6 Mar 2025 14:15:38 GMT, Erik Joelsson wrote:
>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that
>> it's possible to parameterize this for platforms that use different flags
>> for enabling posix threads.
>>
>> This work is a continuation of the work done by Gr
On Thu, 6 Mar 2025 16:38:13 GMT, Aleksey Shipilev wrote:
>> make/autoconf/platform.m4 line 669:
>>
>>> 667: AC_ARG_ENABLE(deprecated-ports,
>>> [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
>>> 668: [Suppress the error when configuring for a deprecated port
>>> @<:@no@:>@
On Thu, 6 Mar 2025 18:15:06 GMT, Magnus Ihse Bursie wrote:
> But if we do not link it with the launcher, it will not get tested. I don't
> think it is a good idea to provide a binary that have not even had a shred of
> testing. I'm rather leaning towards saying that signal chaining is not
> po
27 matches
Mail list logo
