Hello,
Tried to compile and run the following C code on Windows (with
gcc/mingw-w64), and it crashed at the swscanf() call:
#define __USE_MINGW_ANSI_STDIO 1
#include
int
main(void)
{
wchar_t buf[] = L"1 2 3";
wchar_t field[10];
swscanf(buf, L"%ls", field); // crash
wprin
Patch looks ok to me. Jacek any comments?
Thanks
Kai
Am 10.11.2017 21:50 schrieb "Martin Storsjö" :
The CRT parts (especially libmingwex) can't be built with
__MSVCRT_VERSION__=0x1400, so force it to the intended version
there.
Signed-off-by: Martin Storsjö
---
Updated to take a library name a
I am not really the best person to review automake stuff. but for me patch
seems fine. If there are no objections, go ahead and apply.
Thanks
Kai
Am 10.11.2017 21:50 schrieb "Martin Storsjö" :
Install the import library for msvcrt.dll under the name libmsvcrt-os.a,
and install the one that is c
Install the import library for msvcrt.dll under the name libmsvcrt-os.a,
and install the one that is chosen as default as libmsvcrt.a
(which is what all toolchains link to implicitly).
Signed-off-by: Martin Storsjö
---
Updated to always install the current libmsvcrt.a as libmsvcrt-os.a.
---
ming
The CRT parts (especially libmingwex) can't be built with
__MSVCRT_VERSION__=0x1400, so force it to the intended version
there.
Signed-off-by: Martin Storsjö
---
Updated to take a library name as parameter, which is mapped
to a version, as suggested by Jacek.
---
mingw-w64-crt/Makefile.am
On Fri, 10 Nov 2017, JonY via Mingw-w64-public wrote:
On 11/10/2017 09:03 AM, Martin Storsjö wrote:
Libraries that override CPPFLAGS (like lib32_libmsvcrt_a_CPPFLAGS)
don't get AM_CPPFLAGS included automatically. We shouldn't add it
to the CPPFLAGS32 variable that gets used there, because then
On 11/10/2017 08:35 AM, Martin Storsjö wrote:
> Object files in libmingw32 are built with _CRTBLD which means that
> the _CRTIMP attribute in the declaration of __acrt_iob_func becomes
> empty. This means that object files in libmingw32 refer to
> __acrt_iob_func without dllimport.
>
> Define _CRT
On 11/10/2017 09:03 AM, Martin Storsjö wrote:
> Libraries that override CPPFLAGS (like lib32_libmsvcrt_a_CPPFLAGS)
> don't get AM_CPPFLAGS included automatically. We shouldn't add it
> to the CPPFLAGS32 variable that gets used there, because then it
> would get added twice for the object files that
Hi,
For mingw-w64 runtime version x.y.z, I know that __MINGW64_VERSION_MAJOR
will give me the value of x, and __MINGW64_VERSION_MINOR will give me the
value of y.
But what's the symbol that will give me the value of z ?
Is there a symbol that will give me all three values as a string "x.y.z"
Some object files in the crt build were previously built with _CRTBLD,
but not all of them. This lead to these wrappers not defining the
unprefixed function (since that would cause warnings about mismatched
dllimport attributes).
Now that we consistently build these files with _CRTBLD, we can
easi
Libraries that override CPPFLAGS (like lib32_libmsvcrt_a_CPPFLAGS)
don't get AM_CPPFLAGS included automatically. We shouldn't add it
to the CPPFLAGS32 variable that gets used there, because then it
would get added twice for the object files that use the explicit
COMPILE macro (which already include
Object files in libmingw32 are built with _CRTBLD which means that
the _CRTIMP attribute in the declaration of __acrt_iob_func becomes
empty. This means that object files in libmingw32 refer to
__acrt_iob_func without dllimport.
Define _CRTBLD while building acrt_iob_func.c to avoid warnings about
12 matches
Mail list logo
