On 1/10/2019 5:00 AM, Tempelaar E. (Erik) wrote:
I recently reconfigured a build environment for a mingw-built application but I
ran into issues
on Windows 10 caused by a #define _WIN32_WINNT in
C:\msys64\mingw32\i686-w64-mingw32\include\_mingw.h
In my installation it targets WINNT 0x0601
On 12/16/2018 12:58 PM, Maarten Verhage wrote:
Hi Rob,
- Original Message -
From: "sisyphus"
To:
Sent: Sunday, December 16, 2018 04:38
Subject: Re: [Mingw-w64-public] set default sysroot
Hi,
I don't know if you can reset the default without recompiling gcc - I
suspect you can't,
On 12/11/2018 9:25 PM, Liu Hao wrote:
在 2018/12/12 6:04, Earnie via Mingw-w64-public 写道:
On 12/11/2018 4:50 PM, Mateusz Mikuła wrote:
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
On 12/11/2018 4:50 PM, Mateusz Mikuła wrote:
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
Or if you want to use the MSYS2 method look here
On 11/26/2018 1:34 PM, Edward Diener wrote:
On 11/26/2018 10:06 AM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 5:27 PM, Edward Diener wrote:
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
On 11/24/2018 5:27 PM, Edward Diener wrote:
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
distribution, with perhaps an explanation of whether any given file
is used at compile
On 11/24/2018 3:17 PM, Edward Diener wrote:
Is there anywhere a description of the files in a mingw-w64
distribution, with perhaps an explanation of whether any given file is
used at compile, link, run-time, and/or for some other purpose ?
What exactly are you trying to determine? If a file
On 11/23/2018 3:12 PM, Edward Diener wrote:
On 11/23/2018 9:06 AM, Liu Hao wrote:
在 2018/11/23 21:55, Edward Diener 写道:
On 11/22/2018 9:07 PM, Liu Hao wrote:
==> Verifying source file signatures with gpg...
binutils-2.30.tar.bz2 ... FAILED (unknown public key
13FCEF89DD9E3C4F)
==>
So much confusion for something so simple ...
On 11/22/2018 10:30 PM, Liu Hao wrote:
在 2018/11/23 上午10:37, Edward Diener 写道
I do not believe I am trying to upgrade an MSYS2 package. Rather I am
trying to fix a mingw-64/gcc-8.1 installation in Windows itself so that
the binutils part of the
On 11/21/2018 2:12 PM, Marc-André Lureau wrote:
Hi,
Apparently, this is a recurrent question on the web, but I can't find
an answer what is the correct solution. From mingw git repo:
commit 5fe3a72687f0629b68333fa438f4389db790651b
Author: Rafaël Carré
Date: Mon Mar 18 14:21:42 2013 +
On 11/6/2018 4:42 AM, Mateusz wrote:
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
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
> aliased as _ftime for 32-bit libmsvcrt.a.
>
But what about 32bit Win10? Does this idea still
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_t should only be used if _USE_32BIT_TIME_T is set.
_USE_32BIT_TIME_T functions might not be in the MSVCRT.DLL
On 11/2/2018 11:10 AM, Liu Hao wrote:
> 在 2018/11/2 22:41, Earnie via Mingw-w64-public 写道:
>> Maybe add after the "before including any system headers." something
>> like "A value other than 1 causes undefined behavior."
>>
>
> This is overpedantic.
On 11/2/2018 1:38 AM, Liu Hao wrote:
> 在 2018/11/1 22:53, Ozkan Sezer 写道:
>>> Are there any existent projects where `__USE_MINGW_ANSI_STDIO` is
>>> defined as something other than `0` or `1`, if it is defined at all,
>>> including empty?
>>
>> That would be a bug, and I'd recommend applying this
On 11/1/2018 1:22 PM, Mateusz wrote:
> 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 写道:
>>>>
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 realized that we check (in header files)
>>> if
>>> __USE_MINGW_ANSI_STDIO is active in non consistent way:
>>> #if
On 11/1/2018 10:33 AM, Liu Hao wrote:
> 在 2018/11/1 9:52, Mateusz 写道:
>> 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) && ((__USE_MINGW_ANSI_STDIO + 0) != 0)
>>
On 10/30/2018 10:32 PM, Liu Hao wrote:
> 在 2018/10/31 2:01, Jacek Caban 写道:
>> Wine has a test for that with a comment saying that it's supported since
>> Vista:
>> https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/msvcrt/tests/printf.c#l291
>>
>>
>> I changed the test to accept only
On 10/7/2018 10:32 AM, Martin Storsjö wrote:
> On Sun, 7 Oct 2018, Jacek Caban wrote:
>> On 05/10/2018 23:02, Martin Storsjö wrote:
>>
>> It seems tempting to use just standard --includedir here, but
>> I couldn't find a way to change its default value (we'd need
>> to default to
20 matches
Mail list logo
