On Sat, 3 Feb 2024 10:07:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the
On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote:
> This fixes building with GCC 14:
> * ~Cherry-pick a fix from Harfbuzz upstream~
> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>
> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build
On Sat, 3 Feb 2024 10:07:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the
On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a
On Tue, 6 Feb 2024 16:10:38 GMT, Magnus Ihse Bursie wrote:
>> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>>
>>> 29:
>>> 30: ifeq ($(call isTargetOs, linux), true)
>>> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64
>>
>> We have two choices to feel a bit more comfortable:
>> 1) We unconditional
On Thu, 8 Feb 2024 07:41:02 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Fri, 2 Feb 2024 15:49:59 GMT, Magnus Ihse Bursie wrote:
>> I wrote earlier:
>>
>>> There is one change that merit highlighting: In
>>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the
>>> dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e.
>>>
> void *calloc(size_t nmemb, size_t size);
>
>
> So, just swap the number of members and size arguments to match the
> prototype, as
> we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're
> not
> doing anything wrong.
Sam James has upda
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 29 Jan 2024 14:07:49 GMT, Joachim Kern wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> src/java.base/unix/native/libjava/UnixFileSystem_md.c line 6
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
(I'll try look at this during this week.)
-
PR
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regula
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regula
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regula
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> coun
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regula
nsuring that functions will
> always act as their -64 variants on glibc.
Sam James has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes brought in by
the merge/rebase. The pull request contains seven additional commits
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regula
On Fri, 19 Jan 2024 10:06:33 GMT, Kim Barrett wrote:
>> Sam James has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add message for assert
>>
>> Not all C++ stds implement it w/o.
>
> s
nsuring that functions will
> always act as their -64 variants on glibc.
Sam James has updated the pull request incrementally with two additional
commits since the last revision:
- sendfile64 -> sendfile
Signed-off-by: Sam James
- buf64->buf
Signed-off-by: Sam James
--
nsuring that functions will
> always act as their -64 variants on glibc.
Sam James has updated the pull request incrementally with one additional commit
since the last revision:
Add message for assert
Not all C++ stds implement it w/o.
-
Changes:
- all: https://git.openjdk.org
nsuring that functions will
> always act as their -64 variants on glibc.
Sam James has updated the pull request incrementally with one additional commit
since the last revision:
Add off_t static_asserts
Signed-off-by: Sam James
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> coun
On Fri, 15 Dec 2023 12:28:48 GMT, David Holmes wrote:
>From what version of glibc can we be sure that the non-64 version is exactly
>equivalent to the 64 version for all these functions?
Fortunately, support for `_FILE_OFFSET_BITS=64` making `off_t` 64-bit has been
supported for quite a long t
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> coun
The LFS64 symbols provided by glibc are not part of any standard and were gated
behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This
commit replaces the usage of LFS64 symbols with their regular counterparts and
defines -D_FILE_OFFSET_BITS=64, ensuring that functions will al
28 matches
Mail list logo
