Re: [Mingw-w64-public] Rust test failure after some math functions were moved

I don't know how we can check that. The test that failed has nothing to do with math: https://github.com/rust-lang/rust/issues/2214 and I suppose lgamma was picked somewhat randomly as a function that requires FFI and should be universally available. Moving sin and log internal

[Mingw-w64-public] [PATCH] Fix UB in mkstemp retry loop

Signed-off-by: Mateusz Mikuła --- mingw-w64-crt/misc/mkstemp.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c index 3b6246540..7291efcc8 100644 --- a/mingw-w64-crt/misc/mkstemp.c +++ b/mingw-w64-crt

Re: [Mingw-w64-public] [PATCH] Use rand_s in mkstemp function

Dnia środa, 6 marzec 2024 10:09:30 (+01:00), Martin Storsjö napisał(a): > On Mon, 4 Mar 2024, Martin Storsjö wrote: > > > Looking closer at our mkstemp implementation, we have this loop: > > > >/* > >Like OpenBSD, mkstemp() will try at least 2 ** 31 combinations before > >

[Mingw-w64-public] [PATCH] Use rand_s in mkstemp function

Stone on Rust's Zulip server and I was asked to forward it. Co-Authored-By: Josh Stone Signed-off-by: Mateusz Mikuła --- mingw-w64-crt/misc/mkstemp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c index 6b327f

Re: [Mingw-w64-public] Migration from SF and port from Autotools

Dnia wtorek, 4 kwiecień 2023 20:37:20 (+02:00), Jacek Caban via Mingw-w64-public napisał(a): > On 3/31/23 18:24, NightStrike wrote: > > > > > > On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public wrote: > > > > On 3/20/23 16:44, مهدي شينون wrote: > > > Hi everyone, > > >

Re: [Mingw-w64-public] [PATCH] headers: Fix ambigous declaration of the LeaseObtained and LeaseExpires fields of the IP_ADAPTER_INFO structure in iptypes.h

The 32-bit version of the iphlpapi.dll library (where the GetAdaptersInfo function is implemented) expects these two fields (LeaseObtained and LeaseExpires) to be 32-bit. The iptypes.h header declares these fields as time_t. time_t type in the 32-bit build can be either 32-bit or 64-bit,

[Mingw-w64-public] [PATCH] headers: Fix ambigous declaration of the LeaseObtained and LeaseExpires fields of the IP_ADAPTER_INFO structure in iptypes.h

in translation units that use the IP_ADAPTER_INFO structure. I don't feel that's the right approach. IMHO we should just declare these fields as __time32_t or __time64_t depending on the target bitness. From 2ebd2109683a70750d42d357aa57707da58612f4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mateusz

Re: [Mingw-w64-public] [PATCH] crt: Use only __ImageBase symbol in mingw-w64 code

On Sat., 19 Nov 2022 11:54 Pali Rohár wrote: > On Saturday 19 November 2022 17:12:12 LIU Hao wrote: > > 在 2022-11-18 23:40, Pali Rohár 写道: > > > GNU LD provides __ImageBase symbol since 2.19. This is standard windows > > > symbol and should be used instead of custom gnu _image_base__ symbol. > >

Re: [Mingw-w64-public] [PATCH] headers: Fix parameter types in oleauto.h

arameter types in oleauto.h > > > > Signed-off-by: Biswapriyo Nath > > --- > > mingw-w64-headers/include/oleauto.h | 38 ++--- > > 1 file changed, 19 insertions(+), 19 deletions(-) > > Thanks. Patch looks good to me. Pushed. Thank you al

[Mingw-w64-public] [Bug #940] VarDecFromStr should take LPCOLESTR and not OLESTR*

); That is. OLECHAR *strIn should be changed to LPCOLESTR to avoid compile errors like error: invalid conversion from 'LPCOLESTR' {aka 'const wchar_t*'} to 'OLECHAR*' {aka 'wchar_t*'} [-fpermissive] Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Re: [Mingw-w64-public] [PATCH 0/2] Update fwpuclnt exports and build for arm64

czw., 10 mar 2022, 14:05 użytkownik Martin Storsjö napisał: > On Wed, 9 Mar 2022, Jeremy Drake via Mingw-w64-public wrote: > > > It turns out that "cargo" links with fwpuclnt, and efforts to get rust > > working for aarch64-pc-windows-gnu have hit the lack of fwpuclnt.a for > > arm64. > > I'm

Re: [Mingw-w64-public] getc skips "0D" in binary file

setmode(fileno(stdin), O_BINARY); Regards Mateusz W dniu 30.11.2021 o 11:11, David Webb pisze: Sorry if this is old hat - an archives search showed there may have been some discussion of getc and 0D but the query returned 9770 messages and I gave up after the first few hundred. A C linux

Re: [Mingw-w64-public] [PATCH] Enable __MINGW_FORCE_SYS_INTRINS for Clang

Sorry for the late reply. Your description sounds good for me. Since I don't have write access can I ask you to commit it with your description? Thanks Mateusz śr., 31 mar 2021 o 13:53 Martin Storsjö napisał(a): > On Mon, 29 Mar 2021, Mateusz Mikuła wrote: > > > See https://gith

[Mingw-w64-public] [PATCH] Enable __MINGW_FORCE_SYS_INTRINS for Clang

See https://github.com/msys2/CLANG-packages/issues/6 for the details --- mingw-w64-headers/crt/intrin.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h index 4e840fab..250c25b2 100644 ---

[Mingw-w64-public] [PATCH] Enable __MINGW_FORCE_SYS_INTRINS for Clang

See https://github.com/msys2/CLANG-packages/issues/6 for the details --- mingw-w64-headers/crt/intrin.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h index 4e840fab..250c25b2 100644 ---

Re: [Mingw-w64-public] Cross compiling a GTK app for windows from Ubuntu

Hello You also need GTK libraries built for mingw-w64. On Debian (and therefore Ubuntu) AFAIK there are no prebuilt packages so you have to build them on your own. Some other distributions have official and unofficial packages: https://pkgs.org/download/mingw-w64-gtk3

Re: [Mingw-w64-public] Build error with mingw-8.0.0 and gcc-11: multiple definition of `__DTOR_LIST__' / `__CTOR_LIST__

> These are within an #ifndef HAVE_CTOR_LIST. During configure (of > mingw-w64-crt), there's an "checking whether the linker provides > __CTOR_LIST__... yes". If you're running into such an error, it sounds to > me like this test didn't produce the expected result in your case. Can you > have a

Re: [Mingw-w64-public] [PATCH 1/3] crt: Don't run TLS destructors for the main thread if exiting via _exit or ExitProcess

> > It can very well be the case that msys2's builds of libcxx are on top of > libcxxabi even in the regular gcc based sysroots. > It totally is. Long time ago it was easier for me to make it work that way and haven't changed it since. ___

Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.

MSYS2 already overrides default Windows version for mingw-w64 packages: https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55 So no worries about the breakage here. pon., 4 sty 2021 o 12:09 Mateusz Mikuła napisał(a): > MS

Re: [Mingw-w64-public] [PATCH] crt/websocket: move websocket to lib-common

W dniu 24.12.2019 o 17:05, Liu Hao pisze: > 在 2019/12/24 23:29, Mateusz 写道: >> Hi, >> >> After this patch I can't build cross compiler under Ubuntu: >> * >> rm -f lib64/libmincore.a >> cd lib64/ && x86_64-w64-mingw32-ar -M < >>

Re: [Mingw-w64-public] [PATCH] crt/websocket: move websocket to lib-common

387: recipe for target 'lib64/libmincore.a' failed make[1]: *** [lib64/libmincore.a] Error 9 * Regards, Mateusz W dniu 07.12.2019 o 15:56, Biswapriyo Nath pisze: > ... > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-publ

Re: [Mingw-w64-public] Libraries present on Ubuntu but absent from Centos

Fedora/RHEL/CentOS package mingw-w64 differently than Debian/Ubuntu. Libraries you are asking for are located in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/ Regards Mateusz Mikuła czw., 9 maj 2019, 05:01 użytkownik William Zeitler < will...@williamzeitler.com> napisał: > I have

Re: [Mingw-w64-public] [PATCH 2/2] corecrt_wstdlib.h: Add new file and move some relevant declaration to it.

W dniu 02.03.2019 o 20:12, Martin Storsjö pisze: > On Sat, 2 Mar 2019, Mateusz wrote: > >> W dniu 28.02.2019 o 18:31, Jacek Caban pisze: >>> diff --git a/mingw-w64-headers/crt/sec_api/wchar_s.h >>> b/mingw-w64-headers/crt/sec_api/wchar_s.h >>> index ef53aa

Re: [Mingw-w64-public] [PATCH 2/2] corecrt_wstdlib.h: Add new file and move some relevant declaration to it.

t; __DEFINE_CPP_OVERLOAD_SECURE_FUNC_SPLITPATH(errno_t,_wsplitpath_s,wchar_t,_Dest) > - > -#endif > -#endif Now it is deleted one too much '#endif' and then Martin deleted '#ifndef _POSIX_' in [55cc16]. Is this change intentional (delete '#ifndef _POSIX_'/'#endif')? Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] --enable-experimental breaks as

W dniu 27.01.2019 o 18:40, Christer Solskogen pisze: > On 26.01.2019 01:01, Mateusz wrote: > >> For me it looks OK. > > Which version of binutils? It's fixed in master branch. $ gcc -v && ld -v Using built-in specs. COLLECT_GCC=f:\msys\m64-83\bin\gcc.exe COLLECT_LTO_

Re: [Mingw-w64-public] --enable-experimental breaks as

W dniu 25.01.2019 o 10:48, Christer Solskogen pisze: > On 25.01.2019 10:43, Mateusz wrote: >> W dniu 21.01.2019 o 21:20, Christer Solskogen pisze: >>> I've successfully built a multilib compiler on linux targeting both >>> x86_64-w64-mingw32 and i686-w64-mingw32. Usi

Re: [Mingw-w64-public] --enable-experimental breaks as

) with mingw-w64-crt configured with "--enable-experimental" I get > this (on Windows). Could you post your mingw-w64-crt configure options to reproduce the problem (did you use --enable-experimental all or --enable-experimental pri

Re: [Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

It's the mingw-w64-i686-headers-git package where it's defined. Generally partial upgrades of MSYS2 are not supported but if you to be on your own keep in mind crt, headers or winpthreads always have to be in the same version. MSYS2 had to bump WINNT because some package require Windows 7 features

Re: [Mingw-w64-public] Linking fails for GetSaveFileName when cross compiling with MinGW

ple with native mingw-w64 GCC: $ cat t.c #include WCHAR szFile[512]; OPENFILENAMEW Ofn; int main() { Ofn.lStructSize = sizeof(OPENFILENAMEW); Ofn.lpstrFile= szFile; Ofn.nMaxFile = sizeof(szFile)/ sizeof(*szFile); Ofn.Flags = OFN_SHOWHELP | OFN_OVERWRITEPROMPT; GetSaveFileNameW(); retu

Re: [Mingw-w64-public] [PATCH] Add __mingw_access() that works the same for all msvcr*/ucrt libs

W dniu 08.01.2019 o 04:33, Liu Hao pisze: > 在 2019/1/8 8:32, Mateusz 写道: >> W dniu 08.01.2019 o 00:49, JonY pisze: >>> On 1/7/19 5:50 PM, Mateusz wrote: >>>> Old versions of MSVCRT _access() just ignored X_OK, while the >>>> version shipped with Vista,

Re: [Mingw-w64-public] [PATCH] Add __mingw_access() that works the same for all msvcr*/ucrt libs

W dniu 08.01.2019 o 00:49, JonY pisze: > On 1/7/19 5:50 PM, Mateusz wrote: >> Old versions of MSVCRT _access() just ignored X_OK, while the >> version shipped with Vista, returns an error code. >> _access() from msvcr110/120 returns an error code for nul file. >> >>

[Mingw-w64-public] [PATCH] Add __mingw_access() that works the same for all msvcr*/ucrt libs

Old versions of MSVCRT _access() just ignored X_OK, while the version shipped with Vista, returns an error code. _access() from msvcr110/120 returns an error code for nul file. Signed-off-by: Mateusz Brzostek --- mingw-w64-crt/Makefile.am | 2 +- mingw-w64-crt/misc/mingw-access.c | 53

Re: [Mingw-w64-public] [PATCH] GCC: Introduce xaccess function in libiberty

W dniu 06.01.2019 o 16:17, Liu Hao pisze: > 在 2019/1/6 9:19, Mateusz 写道: >> W dniu 05.01.2019 o 20:59, Johannes Pfau pisze: >> Maybe it would make sense to add this in crt/io.h? There's already a >> __USE_MINGW_ACCESS guarded __mingw_access wrapper function which could be &g

Re: [Mingw-w64-public] [PATCH] GCC: Introduce xaccess function in libiberty

W dniu 05.01.2019 o 20:59, Johannes Pfau pisze: > Am 05.01.19 um 18:56 schrieb Mateusz: >> ucrtbase.dll is affected too (msvcr100 works OK), so maybe it is better to >> add your access() function to msvcr110/120 and ucrtbase (as a replacement) >> instead of patchi

Re: [Mingw-w64-public] [PATCH] GCC: Introduce xaccess function in libiberty

return 0; > case X_OK: > // On Windows all files are presumed to be executable. > // They can be opened in a command prompt without any arguments. > return 0; > default: > errno = EINVAL; > return -1; > } > ``` ucrtbase.dll is affected t

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

W dniu 03.01.2019 o 17:05, Jacek Caban pisze: > On 1/3/19 4:47 PM, Jacek Caban wrote: >> Hi Mateusz, >> >> On 1/2/19 5:45 PM, Mateusz wrote: >>> W dniu 02.01.2019 o 16:32, JonY via Mingw-w64-public pisze: >>>> On 1/2/19 1:10 PM, Johannes Pfau wrote:

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

W dniu 02.01.2019 o 20:27, Johannes Pfau pisze: > Am 02.01.19 um 18:02 schrieb Mateusz: >> W dniu 02.01.2019 o 14:10, Johannes Pfau pisze: >>> BTW: How do you handle branches for the patches? The attached patch >>> is against the v6.x branch. >> I didn't read this,

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

If you want to experiment mingw-build allows you to use trunk mingw-w64: https://github.com/niXman/mingw-builds/blob/dba8a4ab94906afe677bf11199b6330e3e1ce8a2/build#L69 GCC 8.1.0 available at mingw-w64 sourceforge page was built from master branch AFAIK. Regards, Mateusz Mikuła śr., 2 sty 2019 o

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

w64/ci/38496499910a580ddc449a7d09f3bc0302767f31/ Regards, Mateusz ___ 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] Add _ftime aliases for all msvcr versions

y/reference/ftime-ftime32-ftime64?view=vs-2017 there is an example program. I've tested this example in 64-bit GCC msvcrt/msvcr120/ucrtbase + 32-bit GCC msvcrt/msvcr120/ucrtbase -- all works. Could you specify example that not works? Regards, Mateusz Test results: $ m64- 82 Mateusz@Mateu

[Mingw-w64-public] MSVC returns aggregate types of up to 8 bytes via EAX register

fun4(void) {     Double v;     v.x = 3.13;     return v; } Mateusz@Mateusz-i7 /c/temp $ g++ -c -Wall -O2 -o t.o t.cpp Mateusz@Mateusz-i7 /c/temp $ objdump -dr t.o t.o: file format pe-x86-64 Disassembly of section .text: <_Z4fun1v>:    0:   f3 0f 10 05 00 00 00    movss 

Re: [Mingw-w64-public] i686 gcc version 8.2?

https://musl.cc works fine, check your DNS. mingw-builds scripts and instructions are available in this repository: https://github.com/niXman/mingw-builds/tree/develop wt., 11 gru 2018 o 22:16 sisyphus napisał(a): > Hi, > > All of those https://musl.cc links are currently unreachable for me

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

W dniu 27.11.2018 o 20:28, Mateusz pisze: > W dniu 27.11.2018 o 17:57, Jacek Caban pisze: >> Signed-off-by: Jacek Caban >> --- >>  mingw-w64-crt/Makefile.am | 8 ++-- >>  1 file changed, 6 insertions(+), 2 deletions(-) > > Thanks! I've added stdio/

Re: [Mingw-w64-public] [PATCH] msvcr80: Provide _set_invalid_parameter_handler compat implementation in libmsvcr80.a.

much better but not perfect. Regards, Mateusz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 26.11.2018 o 23:30, Jacek Caban pisze: > On 11/26/18 10:31 PM, Martin Storsjö wrote: >> On Mon, 26 Nov 2018, Jacek Caban wrote: >> >>> Hi Mateusz, >>> >>> >>> The patch looks mostly good to me. >>> >>> >>>

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 26.11.2018 o 23:30, Jacek Caban pisze: > On 11/26/18 10:31 PM, Martin Storsjö wrote: >> On Mon, 26 Nov 2018, Jacek Caban wrote: >> >>> Hi Mateusz, >>> >>> >>> The patch looks mostly good to me. >>> >>> >>>

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 26.11.2018 o 12:36, Jacek Caban pisze: > Hi Mateusz, > > > The patch looks mostly good to me. > > > On 23/11/2018 22:37, Mateusz wrote: >> --- a/mingw-w64-headers/crt/stdio.h >> +++ b/mingw-w64-headers/crt/stdio.h >> @@ -609,31 +609,20 @@ int vsnpr

Re: [Mingw-w64-public] Description of files in a mingw-w64 distribution

There is https://github.com/niXman/mingw-builds/tree/develop sob., 24 lis 2018 o 23:28 Edward Diener napisał(a): > On 11/24/2018 5:18 PM, Earnie via Mingw-w64-public wrote: > > On 11/24/2018 3:17 PM, Edward Diener wrote: > >> Is there anywhere a description of the files in a mingw-w64 > >>

Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro

Changelog for release and git version differ a lot and it won't apply cleanly. Your should get rid of Changelog part and it will work. sob., 24 lis 2018 o 22:58 Edward Diener napisał(a): > On 11/24/2018 1:21 AM, Liu Hao wrote: > > 在 2018/11/24 13:30, Edward Diener 写道: > >> ==> Starting

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 22.11.2018 o 09:51, Mateusz pisze: > W dniu 21.11.2018 o 23:39, Martin Storsjö pisze: >> On Wed, 21 Nov 2018, Mateusz wrote: >> >>> Problem is in libstdc++.a which uses fseeko64 from libmingwex. >>> >>> My proposition is: >>> we

Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro

possible, in order to succeed. Now I'm testing new patch for mingw-w64 so I rebuild GCC 7.3.1 with new patch and binutils from current git -- you can try if ld.exe from this binaries works for you. www.msystem.waw.pl/x265/mingw-gcc731-20181123.7z Regards, Mateusz _

Re: [Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

W dniu 21.11.2018 o 23:39, Martin Storsjö pisze: > On Wed, 21 Nov 2018, Mateusz wrote: > >> Problem is in libstdc++.a which uses fseeko64 from libmingwex. >> >> My proposition is: >> we could build two libmingwex -- libmingwex for msvcrt and libmingwex10 for >>

Re: [Mingw-w64-public] Why is inet_pton() not declared?

Your example works fine with mingw-w64 6.0.0. You can see function definition here: https://gitlab.com/mati865/mingw-w64-mirror/blob/master/mingw-w64-headers/include/ws2tcpip.h#L444 śr., 21 lis 2018 o 22:49 Marc-André Lureau napisał(a): > Hi > On Thu, Nov 22, 2018 at 1:33 AM Earnie via

[Mingw-w64-public] Problems with fseeko64, libstdc++ and ucrt builds

need to execute automake in mingw-w64-crt folder before build). Now I can build and execute x265 (ucrt build). I am not sure if it is the best way -- to make two libmingwex* and only one libstdc++. So my question is -- we should go in this direction or not? Regards, Mateusz diff --git a/mingw

Re: [Mingw-w64-public] [PATCH] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

W dniu 06.11.2018 o 04:58, Earnie via Mingw-w64-public pisze: > On 11/5/2018 11:49 AM, Mateusz wrote: > >> functions. In my patch we use _ftime32 and _ftime64 functions and we define >> _ftime to _ftime32 or _ftime64. It should work on WinXP because _ftime32 is >> alia

Re: [Mingw-w64-public] [PATCH] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

W dniu 05.11.2018 o 16:53, Earnie via Mingw-w64-public pisze: > On 11/4/2018 2:02 PM, Mateusz wrote: > >> (but in _mingw.h we always define _USE_32BIT_TIME_T for 32-bit) > > This is a wrong implementation. 32-bit Windows supports 64-bit time_t. > 32-bit time_

[Mingw-w64-public] [PATCH] timeb.h: declare _ftime32 function, define _ftime according to _USE_32BIT_TIME_T

are only _ftime and _ftime64 functions. In header files we could declare *32 functions and define _ftime and _ftime_s according to _USE_32BIT_TIME_T. I've attached patch that do this. Sample program should be compiled with -DMINGW_HAS_SECURE_API option. Please review. Regard

Re: [Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

W dniu 04.11.2018 o 10:30, Liu Hao pisze: > 在 2018/11/3 4:28, Mateusz 写道: >> I've attached new version of this patch that works with current tip. >> >> I've added patch 0002 that sets printf format attribute according to new >> logic in inttypes.h. >> >> Reg

Re: [Mingw-w64-public] [PATCH] headers: Update the threadlocinfo struct for ucrt

type.h > @@ -209,8 +209,13 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); > #endif > > #define __chvalidchk(a,b) (__PCTYPE_FUNC[(unsigned char)(a)] & (b)) > +#ifdef __MSVCRT_VERSION__ >= 0x1400 And here also. Regards, Mateusz ___ 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] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

W dniu 01.11.2018 o 14:16, JonY pisze: > On 11/01/2018 01:52 AM, Mateusz wrote: >> During discussion about inttypes I realized that we check (in header files) >> if >> __USE_MINGW_ANSI_STDIO is active in non consistent way: >> #if defined(__USE_MINGW_ANSI_STDIO) &

Re: [Mingw-w64-public] [PATCH] inttypes.h: Take into account __USE_MINGW_ANSI_STDIO and msvcrt version instead of depending on _mingw_print_p*.h headers.

file:542: recipe for target 'all' failed make: *** [all] Error 2 Should I do something special to test this patch? Regards, Mateusz ___ 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] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

W dniu 01.11.2018 o 16:06, Earnie via Mingw-w64-public pisze: > On 11/1/2018 10:53 AM, Earnie wrote: >> >> >> On 11/1/2018 10:33 AM, Liu Hao wrote: >>> 在 2018/11/1 9:52, Mateusz 写道: >>>> During discussion about inttypes I rea

[Mingw-w64-public] [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h

Regards, Mateusz From fdd383cbb0e636c609c19f78f1c0655d94f0c4e5 Mon Sep 17 00:00:00 2001 From: Mateusz Date: Thu, 1 Nov 2018 01:07:37 +0100 Subject: [PATCH] Always define __USE_MINGW_ANSI_STDIO as 0 or 1 in _mingw.h We check state of __USE_MINGW_ANSI_STDIO in many places. This patch checks all corn

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 30.10.2018 o 17:04, Liu Hao pisze: > 在 2018/10/30 23:48, Mateusz 写道: >> Liu Hao example is the explanation. >> printf("value = %" PRIx64 "\n", value); >> should print 64-bit int 'value' regardless stdio.h is included or not. >> >> > &

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 30.10.2018 o 13:59, Jacek Caban pisze: > On 10/28/2018 10:28 PM, Mateusz wrote: >> W dniu 28.10.2018 o 16:07, Jacek Caban pisze: >>> >>> On 28/10/2018 09:39, Liu Hao wrote: >>>> 在 2018/10/27 19:52, Jacek Caban 写道: >>>>> I don't se

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 27.10.2018 o 13:46, Vincent Torri pisze: > On Fri, Oct 26, 2018 at 11:58 PM Mateusz wrote: >> >> W dniu 26.10.2018 o 22:35, Tom Ritter pisze: >>> This is not really a MinGW problem, but MinGW does diverge from other >>> compilers and it caused Firefox to c

Re: [Mingw-w64-public] inttypes Format Specifiers

e in the first place, we don't need to redefine it later. Now if it is defined __USE_MINGW_ANSI_STDIO and stdio.h is NOT included, it is I64x, with your patch it is changed to llx (that not works with msvcrt.dll without miracles from stdio.h). Maybe it is simpler to leave *_pop.h and *_push.h l

Re: [Mingw-w64-public] inttypes Format Specifiers

W dniu 26.10.2018 o 22:35, Tom Ritter pisze: > This is not really a MinGW problem, but MinGW does diverge from other > compilers and it caused Firefox to crash. > > MinGW defines a lot of I64[foo] format specifiers in inttypes.h. > clang and clang-cl don't use I64[foo] they use ll[foo]. (I64[foo]

Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__

W dniu 31.08.2018 o 12:17, Martin Storsjö pisze: > On Aug 31, 2018, at 12:51, Mateusz wrote: >> >> W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >>>> On Aug 29, 2018, at 18:44, Martell Malone wrote: >>>> >>>> LGTM. >>> >>>

Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__

W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >> On Aug 29, 2018, at 18:44, Martell Malone wrote: >> >> LGTM. > > Pushed this version. > > // Martin It's not working for me (when I build gcc on ubuntu). Could

Re: [Mingw-w64-public] [PATCH] _mingw.h.in: Improve clang support.

I think it's upstream clang bug reported here: https://github.com/Alexpux/MINGW-packages/issues/1677#issuecomment-394906508 wt., 26 cze 2018 o 13:57 Liu Hao napisał(a): > 在 2018/6/26 19:33, Jacek Caban 写道: > > I did tests with c89 and c99 before submitting the patch (C++ is > > irrelevant, I

Re: [Mingw-w64-public] [PATCH] headers: Complete the winnt.h structs/defines for ARM64

There is a bug reported for this commit: https://sourceforge.net/p/mingw-w64/bugs/736/ pon., 19 mar 2018 o 07:30 Martin Storsjö napisał(a): > On Mon, 19 Mar 2018, Liu Hao wrote: > > > 在 03/19/2018 03:12 AM, Martin Storsjö 写道: > >> Sync the latest version from wine. > >> > >> Signed-off-by:

Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails

W dniu 06.05.2018 o 04:17, JonY via Mingw-w64-public pisze: > On 05/05/2018 11:46 AM, Mateusz wrote: >> W dniu 05.05.2018 o 11:57, JonY via Mingw-w64-public pisze: >>> On 05/04/2018 02:49 PM, Mateusz wrote: >>>> The patch is only in master (v6) branch >>>>

Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails

W dniu 05.05.2018 o 11:57, JonY via Mingw-w64-public pisze: > On 05/04/2018 02:49 PM, Mateusz wrote: >> The patch is only in master (v6) branch >> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/3ce3e27f044935f19e93e80c43ca695262d484e1/ >> >> JonY could you backpor

Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails

The patch is only in master (v6) branch https://sourceforge.net/p/mingw-w64/mingw-w64/ci/3ce3e27f044935f19e93e80c43ca695262d484e1/ JonY could you backport this patch to v5.x branch? Mateusz W dniu 04.05.2018 o 16:32, JonY via Mingw-w64-public pisze: > On 05/04/2018 12:35 PM, Christer Solsko

Re: [Mingw-w64-public] mingw-w64 and clang C++ ABI compatibility

Those are Clang bugs [0]. Multiple definitions error has been fixed in [1] and probably (just guessing) made it to Clang 6.0.0 release. Undefined references bug happens when you link code compiled by Clang to static libstdc++ (and probably other static libs too) compiled by GCC. I think there is

Re: [Mingw-w64-public] GCC Fallthrough warnings.

There is no patch attached. 2018-03-10 0:32 GMT+01:00 : > When compiling with GCC 7.3.0, I got warnings about falltrhoughts and I mad > e patch for this that I'm attaching to this E-Mail. > > >

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: do not define _xgetbv for GCC 8

W dniu 30.01.2018 o 10:51, Jacek Caban pisze: > Hi Mateusz, > > > On 1/22/18 9:18 PM, Mateusz wrote: >> GCC 8 from r248028 has defined function _xgetbv and we should >> avoid double definition of this function. >> >> Please review. >> > > The patc

[Mingw-w64-public] [PATCH] intrin-impl.h: do not define _xgetbv for GCC 8

GCC 8 from r248028 has defined function _xgetbv and we should avoid double definition of this function. Please review. Mateusz From 5aa15ee4a5f04cdc797deb685d23dc67275af357 Mon Sep 17 00:00:00 2001 From: Mateusz <mateu...@poczta.onet.pl> Date: Mon, 22 Jan 2018 20:58:48 +0100 Subject:

[Mingw-w64-public] About [PATCH] intrin-impl.h: Use volatile argument for __buildbittesti-based functions.

%[Offset]}" __FLAGSET, "J") in the last line in the second param '__int64 volatile' could/should be without volatile (which is always added by __buildbittesti macro). Apart from that the patch is OK for me. Mateusz --

[Mingw-w64-public] __MINGW_GNUC_PREREQ vs clang

Clang defines itself as GCC 4.2.1 which can cause issues like multiple definitions of `__m64`, `__m128`, ... coming from crt/intrin.h when `-march=i686` is used when building compiler-rt. When I override it for clang to return false compiler-rt builds fine with `-march=i686`. I think it's a good

Re: [Mingw-w64-public] _ftelli64 bug

You can try linking to different version of runtime library [0] like MSVC does by default. [0] https://stackoverflow.com/questions/3402252/how-to-link-against-msvcr90-dll-with-mingw-gcc 2017-10-19 10:54 GMT+02:00 Etienne Sandré-Chardonnal : > Hi, > > I don't think this

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

The discussion is about master branch. 2017-10-16 4:53 GMT+02:00 Jean-Baptiste Kempf : > Hello, > > Could we keep XP for the 5.0 release and then drop it after? > > For VLC, we will keep XP compatibility for the next major release, in a > few days, and then drop it totally. >

Re: [Mingw-w64-public] [PATCH] headers: Add casts in ua_wcs*chr in stralign.h

Storsjö > On Fri, 25 Aug 2017, Mateusz Mikuła wrote: > >> There was discussion if this should be done via cast or union, both >> versions were attached at some point of [1] discussion. >> >> [1] https://sourceforge.net/p/mingw-w64/mailman/message/35923114/ > > Oh, I

Re: [Mingw-w64-public] [PATCH] headers: Add casts in ua_wcs*chr in stralign.h

There was discussion if this should be done via cast or union, both versions were attached at some point of [1] discussion. [1] https://sourceforge.net/p/mingw-w64/mailman/message/35923114/ 2017-08-25 11:12 GMT+02:00 Martin Storsjö : > When building libcxx, a version of wcschr

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

Ping On Sat, 2017-06-04 at 15∶31 +0200, Mateusz Mikuła wrote: > > > I sent patch casting to PUWSTR_C half hour after first message > when I noticed how stupid it was before. > > > > Should still apply cleanly (attachment has

Re: [Mingw-w64-public] [PATCH] remove cast to int from mantissa for __mingw_printf

All patches for mingw-64 should be signed off. -- Original Message -- Subject: [Mingw-w64-public] [PATCH] remove cast to int from mantissa for __mingw_printf Date: Mon, 12 Jun 2017 16:24:17 +0100 To: Mingw-w64-public From: Martell Malone > In this thread

Re: [Mingw-w64-public] static lib/Visual Studio problem

> However, once I try to use some more c++ features, I get the > following > error, and it seems to be associated with the compiled object files > themselves: > > "invalid or corrupt file: no symbol for COMDAT section ..." (and a > hex > address). It's not possible to mix static libstdc++ with

Re: [Mingw-w64-public] [HELP] Need to emulate _get_current_locale

On Windows 10 it is builtin in msvcrt.dll: $ winedump -j export '/media/mateusz/C/Windows/System32/msvcrt.dll' | grep locale   00028CB0   227 _create_locale   00029000   308 _free_locale   000290C0   336 _get_current_locale   0002E710  1004 _wsetlocale   0002F5D0  1153 localeconv   00029970  1203

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

reason for it not to become a default warning). > > A C-style cast is perfectly appropriate here, no union needed. > > FTR, it’s not only Clang which doesn’t accept the pre-patch code, GCC > errors too. > > Best, Norbert. > > On Sun, Jun 4, 2017 at 12:18 PM Mateusz Miku

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

Anything to improve? From 05bc4cbc93f5f9942fc28a578dc1afa68d69daa2 Mon Sep 17 00:00:00 2001 From: Mateusz Mikula <mati...@gmail.com> Date: Sun, 4 Jun 2017 11:33:22 +0200 Subject: [PATCH] cast ua_wcschr and ua_wcsrchr returns when WSTR_ALIGNED is true Clang doesn't allow implicit conversio

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

0x0502 is Windows Server 2003 If changing default target it should be done properly. Windows Vista is EOL and it's share is lower than XP so I'd vote for Windows 7. -- Original Message -- Subject: [Mingw-w64-public] Default _WIN32_WINNT version too low? Date: Sat, 3 Jun 2017 18:27:40

Re: [Mingw-w64-public] C++ cout executable size

Pasted wrong link, here is fixed https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/ios_base.h#L601 On June 3, 2017 10:11:30 AM GMT+02:00, "Mateusz Mikuła" <mati...@gmail.com> wrote: >Here is ios_base::Init >https://github.com/gcc-mirror/gcc/blob/m

Re: [Mingw-w64-public] C++ cout executable size

Here is ios_base::Init https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/iostream#L74 If you really want to understand what compiler put into your executable you have to disassemble it. Bear in mind that even if you knew whole source code of libstdc++ you would get

[Mingw-w64-public] Problem with GCC 8 and _xgetbv

ter idea how to fix this, it will be appreciated. Mateusz -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-

Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by unprivileged users

Are you sure 0x3 value (0x1 | 0x2) is valid for VALID_SYMBOLIC_LINK_FLAGS on every OS from 7 to 10? Dnia 2017-05-27, sob o godzinie 11:14 +, Samuel Leslie pisze: > The MSDN documentation doesn't appear to have been updated yet: >

Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

t about '__in' and '__out' that we recommend '_In_' and '_Out_' in source code instead of '__in' and '__out'. Mateusz > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites,

Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

We could roll back commit [b7f44b]. Now there are new commits and this should be fixed. Mateusz > > > 2017-05-17 12:34 GMT+02:00 Mateusz <mateu...@poczta.onet.pl>: >> We really should do something

[Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

We really should do something with '__in' and '__out' from driverspecs.h. Please review. mingw-w64-headers/include/driverspecs.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/driverspecs.h b/mingw-w64-headers/include/driverspecs.h index

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

W dniu 2017-05-15 o 08:51, Liu Hao pisze: > On 2017/5/11 23:11, Kai Tietz wrote: >> I would prefer this too, but I don't believe that we can convince >> libstdc++ maintainers to modify their code for this. Sadly the MS' >> platform sdk defines a lot of stuff, which collides some times with >>

  1   2   >