Re: [Mingw-w64-public] [PATCH 08/10] headers: Fix declaration of POSIX stat/fstat and LFS stat64/fstat64 functions

2025-05-10 Thread Christoph Reiter
This change seems to break the 64bit msvcrt build for gcc: x86_64-w64-mingw32\bin\ld.exe: ada/adaint.o:adaint.c:(.text+0x4375): undefined reference to `fstat64' Here a smaller reproducer: $ cat x.c #include int main( void ) { struct stat64 something; fstat64(0, &something); return 0;

Re: [Mingw-w64-public] [PATCH] headers: undef register in case projects define it.

2024-12-30 Thread Christoph Reiter
On Mon, Dec 30, 2024 at 9:47 PM Jacek Caban wrote: > As I mentioned in the other thread, doxygen appears to tamper with the > register definition only for outdated flex versions. If that’s the case, > this might be an MSYS2 packaging issue. Are there other instances of > similar problems? Good ca

Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.

2023-10-30 Thread Christoph Reiter
On Mon, Oct 30, 2023 at 9:54 PM Jacek Caban via Mingw-w64-public wrote: > However, looking at _pthread_wait_for_*_objects helpers, I'd argue that > they don't make sense in the first. The comment claims that system > functions have poor accuracy and then uses a function with the same > accuracy to

[Mingw-w64-public] [PATCH] genpeimg: fix build error with clang v16

2023-04-02 Thread Christoph Reiter
Building genpeimg with clang v16 fails like: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion] pe->is_64bit = 1; is_64bit is always ever comapred against 0 in our case, so the value change does

Re: [Mingw-w64-public] _FILE_OFFSET_BITS + stat macro + conflicts

2022-01-21 Thread Christoph Reiter
On Fri, Jan 21, 2022 at 6:47 PM LRN wrote: > > On 21.01.2022 17:32, Christoph Reiter wrote: > > > > when _FILE_OFFSET_BITS is defined (ideally Windows code shouldn't > > depend on it, but here we are) mingw-w64 does this: > > > > ht

[Mingw-w64-public] _FILE_OFFSET_BITS + stat macro + conflicts

2022-01-21 Thread Christoph Reiter
Hey, when _FILE_OFFSET_BITS is defined (ideally Windows code shouldn't depend on it, but here we are) mingw-w64 does this: https://github.com/mingw-w64/mingw-w64/blob/898141aa957b99812f2f4d2cf89255798d578d54/mingw-w64-headers/crt/sys/stat.h#L279 Which replaces various things called "stat" in som

Re: [Mingw-w64-public] [PATCH] crt/stdlib: Add `quick_exit()` and `at_quick_exit()` for UCRT

2021-05-23 Thread Christoph Reiter
On Sat, May 22, 2021 at 4:14 AM Liu Hao wrote: > > 在 2021-05-22 00:30, Christoph Reiter 写道: > > It compiles and runs fine, but gcc still fails to build with current > > master with the same error. Both on CI and locally. > > Ah, I see. It's because either or is in

Re: [Mingw-w64-public] [PATCH] crt/stdlib: Add `quick_exit()` and `at_quick_exit()` for UCRT

2021-05-21 Thread Christoph Reiter
On Sun, Apr 25, 2021 at 6:06 PM Liu Hao wrote: > Does this program compile and run with that commit? > > ``` > #define _GLIBCXX_HAVE_QUICK_EXIT 1 > #include > > int main() >{ > ::std::quick_exit(0); >} > ``` It compiles and runs fine, but gcc still fails to build with current master

Re: [Mingw-w64-public] stdio.h: redefinition issues with UCRT

2021-05-16 Thread Christoph Reiter
On Sun, May 16, 2021 at 11:58 AM Liu Hao wrote: > Who was it that added the `#define`? Users should have known that `_snprintf` > does not > null-terminate the output string if there is no enough room in the output > buffer, which is rather > dangerous. Some projects I've seen it in: gimp, silc

[Mingw-w64-public] UCRT: Issues with HUGE and _HUGE macros

2021-05-15 Thread Christoph Reiter
This works with msvcrt but fails with ucrt. Noticed this while building graphviz. HUGE_VAL works, while _HUGE and HUGE fail. #include #include int main(void){ printf("%f %f %f\n", HUGE, _HUGE, HUGE_VAL); return 0; } C:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64

[Mingw-w64-public] stdio.h: redefinition issues with UCRT

2021-05-15 Thread Christoph Reiter
Hey, while trying to get everything to build with UCRT in MSYS2 we noticed quite a few errors that come down to the following: // gcc -D__USE_MINGW_ANSI_STDIO=1 a.c #define snprintf _snprintf #include int main (){return 0;} i.e. snprintf is defined before stdio.h, messing it up I see that stdi

Re: [Mingw-w64-public] [PATCH] crt/stdlib: Add `quick_exit()` and `at_quick_exit()` for UCRT

2021-04-25 Thread Christoph Reiter
Someone reported a build error using this commit with the logs referencing quick_exit(). Could this be related? https://github.com/r-windows/rtools-testing/runs/2420378991?check_suite_focus=true (you need to be logged in to see the logs) regards ___ M

Re: [Mingw-w64-public] [ANN] MSYS2 64bit UCRT Environment (UCRT64)

2021-04-16 Thread Christoph Reiter
On Fri, Apr 16, 2021 at 9:48 PM Martin Storsjö wrote: > Do the packaging contain hooks for running some sort of test suites for > the built packages too? Some contain one [0], but they don't get run in CI since not many projects make sure their tests run/pass on Windows. Ideally we would integrat

Re: [Mingw-w64-public] [ANN] MSYS2 64bit UCRT Environment (UCRT64)

2021-04-16 Thread Christoph Reiter
On Wed, Mar 31, 2021 at 10:41 PM Christoph Reiter wrote: > * We currently have ~250 of ~1850 packages built Small update: We are now at ~1500 packages ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net ht

[Mingw-w64-public] [ANN] MSYS2 64bit UCRT Environment (UCRT64)

2021-03-31 Thread Christoph Reiter
Hey everyone, over the last two weeks MSYS2 [0] gained a new ucrt based environment: * 64bit only, and no plans for 32bit at the moment * Access via C:/msys64/ucrt64.exe for example * Package names start with "mingw-w64-ucrt-x86_64-" Example: "pacman -S mingw-w64-ucrt-x86_64-gtk3" * We currentl

Re: [Mingw-w64-public] [PATCH] headers: add missing _W_* lconv struct members

2021-02-17 Thread Christoph Reiter
On Tue, Feb 16, 2021 at 6:00 AM Liu Hao wrote: > Thanks. I pushed this one. Thank you! ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] headers: add missing _W_* lconv struct members

2021-02-14 Thread Christoph Reiter
#x27;ve attached a new patch. Thanks! From c56533ba8817ea246d474bd94491f02a0a2d16cd Mon Sep 17 00:00:00 2001 From: Christoph Reiter Date: Tue, 22 Dec 2020 21:47:31 +0100 Subject: [PATCH] headers: add missing _W_* lconv struct members This seems to have been added with MSVCR100 but is also available in MSVCRT on Wind

Re: [Mingw-w64-public] [PATCH] headers: add missing _W_* lconv struct members

2020-12-23 Thread Christoph Reiter
On Wed, Dec 23, 2020 at 6:35 AM Liu Hao wrote: > These fields seem to have been added since MSVCR100, so please add a > necessary check for > `__MSVCRT_VERSION__`. > > This also means that CPython has to define `__MSVCRT_VERSION__` in order to > use them. Hm, I see. The fields seem to work fine

Re: [Mingw-w64-public] [PATCH] headers: add missing _W_* lconv struct members

2020-12-22 Thread Christoph Reiter
On Tue, 2020-12-22 at 15:59 -0500, Zach Bacon wrote: > I think you forgot to attach your patch. Another try with a different client. From 27f7780ab3ca66b175aadc55ebe6f714ab371c71 Mon Sep 17 00:00:00 2001 From: Christoph Reiter Date: Tue, 22 Dec 2020 21:47:31 +0100 Subject: [PATCH] headers:

Re: [Mingw-w64-public] [PATCH] headers: add missing _W_* lconv struct members

2020-12-22 Thread Christoph Reiter
On Tue, Dec 22, 2020 at 10:00 PM Zach Bacon wrote: > > I think you forgot to attach your patch. I did not :) but I'm also just using gmail here, so maybe it's due to that? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https:

[Mingw-w64-public] [PATCH] headers: add missing _W_* lconv struct members

2020-12-22 Thread Christoph Reiter
Newest CPython requires these thanks ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public