Re: [Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

On 2017/11/17 11:36, Liu Hao wrote: > On 2017/11/15 9:54, Liu Hao wrote: >> This patches addresses the issue in >> . >> >> The C99 standard treats %s, %c, %ls and %lc identically in *scanf and >> w*scanf, >> hence this patch is merely

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

It seems the real problem is that the build tries to compile "pex-unix.c" in the liberty sources instead of "pex-win32.c". And this in a build stage where the new x86_64-w64-mingw32-gcc & environment is already used. That points in the direction of a perhaps buggy configure script in the case of a

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

I have changed the gcc build mode from --disable-bootstrap to --enable-bootstrap with the last build. (That's normally the correct way, the --disable-bootstrap slipped in accidentally from earlier tests.) The missing defines are nowhere in the "raw" mingw64 distribution, so I assume libiberty would

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

On Tue, 21 Nov 2017, Sven Kretzschmar wrote: Thanks - now the cross compilation goes much further resulting in the below error (trying to cross-compile x86_64-w64-mingw32-gcc with libiberty support & ucrtbase option, other options as before, bootstrapping enabled). Normally, the undeclared symb

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Thanks - now the cross compilation goes much further resulting in the below error (trying to cross-compile x86_64-w64-mingw32-gcc with libiberty support & ucrtbase option, other options as before, bootstrapping enabled). Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) are de

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

2017-11-21 11:36 GMT+01:00 Martin Storsjö : > On Tue, 21 Nov 2017, Martin Storsjö wrote: > >> On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote: >> >>> Hi, >>> >>> Why was 'DllGetVersion' removed? Otherwise patch is ok. >> >> >> It wasn't present in the libarm32 version of this, and I thoug

Re: [Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

>__MINGW_IMPORT (which expands to dllimport) ah, that's right. Sorry, I missed that. I thought these global variables was declared with extern(w/o dllimport) in the samy way as other global variables. From: Martin Storsjö Sent: 21 November 2017 13:43 To

Re: [Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

On Tue, 21 Nov 2017, Yuta Nakai wrote: Attached patch fixes the definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll. These are global variables and exported as DATA symbols, so we should use __MINGW_IMP_SYMBOL. In which case do you see an actual difference in behaviour compar

[Mingw-w64-public] Fix definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll.

Attached patch fixes the definitions of _daylight/_dstbias/_timezone/_tzname for msvcr*.dll. These are global variables and exported as DATA symbols, so we should use __MINGW_IMP_SYMBOL.From 7c414985d86ae49ba9d7a856201b8f1db103330e Mon Sep 17 00:00:00 2001 From: Yuta Nakai Date: Tue, 21 Nov 201

Re: [Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Patch is ok. Please go ahead and apply. Pushed, thanks! // Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Sla

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

On Tue, 21 Nov 2017, Martin Storsjö wrote: On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hi, Why was 'DllGetVersion' removed? Otherwise patch is ok. It wasn't present in the libarm32 version of this, and I thought it was one of the runtime dll entry points that one didn't real

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

On Tue, 21 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hi, Why was 'DllGetVersion' removed? Otherwise patch is ok. It wasn't present in the libarm32 version of this, and I thought it was one of the runtime dll entry points that one didn't really want to link toso that it wouldn't matter

Re: [Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

Hi, Why was 'DllGetVersion' removed? Otherwise patch is ok. Thanks, Kai 2017-11-21 9:15 GMT+01:00 Martin Storsjö : > Use the new shared def file for arm64 as well. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/{lib64 => lib-common}/shlwapi.def | 15 +- > mingw-w64-crt/libarm32/shlwa

Re: [Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

Patch is ok. Please go ahead and apply. Thanks, Kai 2017-11-21 9:14 GMT+01:00 Martin Storsjö : > GCC throws an error when faced with "static static", while clang > handles it fine. > > _mingw_mac.h defines __mingw_static_ovr to be a version of __mingw_ovr > that always is static (the normal __min

[Mingw-w64-public] [PATCH] crt: Share shlwapi.def between lib64 and libarm32

Use the new shared def file for arm64 as well. Signed-off-by: Martin Storsjö --- mingw-w64-crt/{lib64 => lib-common}/shlwapi.def | 15 +- mingw-w64-crt/libarm32/shlwapi.def | 935 mingw-w64-crt/libarm64/Makefile.am | 1 + 3 files changed, 13

[Mingw-w64-public] [PATCH] headers: Avoid producing repeated "static static" in __mingw_static_ovr

GCC throws an error when faced with "static static", while clang handles it fine. _mingw_mac.h defines __mingw_static_ovr to be a version of __mingw_ovr that always is static (the normal __mingw_ovr is plain "inline __cdecl" in C++, while it does include "static" in C). However, swprintf.inl and

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

On Mon, 20 Nov 2017, Sven Kretzschmar wrote: Hi, Thanks a lot for all your work on this project ! :) I am using the newest master branch of mingw64 from https://github.com/mirror/mingw-w64/tree/master . GCC version used is: https://github.com/gcc-mirror/gcc/tree/gcc-6_4_0-release (6.4.0) And