> From:
> Date: Tue, 12 Sep 2017 10:05:12 +1000
>
> Not sure what to make of the format warnings (I'll leave that to others),
> but I think the post that you cited does reveal an instance of Emacs doing
> something wrong wrt the redefining of _WIN32_WINNT.
> This symbol appears to be redefined
-Original Message-
From: Eli Zaretskii
Sent: Tuesday, September 12, 2017 3:19 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] Problems with using printf format specs with GCC
7
Does Emacs do anything wrong in these cases?
Not sure what to make of the format
On 09/11/2017 05:19 PM, Eli Zaretskii wrote:
> Hi,
>
> Kindly take a look at the issues with building current development
> sources of GNU Emacs with MinGW64, described here:
>
> http://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00171.html
>
> The build emits a lot of warnings related t
On Mon, 11 Sep 2017, Jacek Caban wrote:
Hi Martin,
On 11.09.2017 14:48, Martin Storsjö wrote:
+_ctime32
+; _ctime32_s replaced by emu
+_ctime64
+; _ctime64_s replaced by emu
This doesn't look right, we should use .def file to expose those. I
noticed a few similar other cases in the patch.
On Mon, 11 Sep 2017, Jacek Caban wrote:
Please review.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/sal.h | 3 +++
1 file changed, 3 insertions(+)
Not familiar with this header before, but given the rest of the file, this
patch seems like it'd be ok - so ok for me.
// Martin
-
Hi,
Kindly take a look at the issues with building current development
sources of GNU Emacs with MinGW64, described here:
http://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00171.html
The build emits a lot of warnings related to printf specifications for
printing 64-bit integral values.
Please review.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/sal.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mingw-w64-headers/include/sal.h b/mingw-w64-headers/include/sal.h
index 9088d5ab..0a2df8b4 100644
--- a/mingw-w64-headers/include/sal.h
+++ b/mingw-w64-headers/in
Hi Martin,
On 11.09.2017 14:48, Martin Storsjö wrote:
> +_ctime32
> +; _ctime32_s replaced by emu
> +_ctime64
> +; _ctime64_s replaced by emu
This doesn't look right, we should use .def file to expose those. I
noticed a few similar other cases in the patch.
In general, we should use as few com
This def file is originally based on wine's spec file for this
DLL, but with manual modifications made on top in the same style
as the manual edits in msvcrt.def.in.
Signed-off-by: Martin Storsjö
---
v3: No changes.
v4: No changes.
---
mingw-w64-crt/Makefile.am| 16 +-
mingw-w
Map the common standard C stdio functions to the ucrtbase.dll
implementations.
The ucrtbase stdio functions can function in a number of different
modes; in the old legacy msvcrt.dll compatible mode, or in C99
compatible mode. Legacy functions such as _snprintf keep their old
behaviour, while snpri
This intercepts the function calls that the mingw CRT startup and
other libmingwex helpers expect to use, that no longer is available on
ucrtbase.dll.
This allows using the same CRT startup object files and libmingwex both
with the normal msvcrt.dll and with ucrtbase.dll, instead of having to
rebu
Hi,
This is the fourth round of this patchset - the only modification
since the last round is that I've tested building libc++ and a C++
hello world with it, and fixed those issues I ran into in that setup.
I think most of my open questions have been answered in one way or
another. This is by no
On Fri, 8 Sep 2017, JonY via Mingw-w64-public wrote:
On 09/08/2017 06:48 AM, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/misc/mingw_getsp.S | 5 -
mingw-w64-headers/crt/setjmp.h | 26 ++
2 files changed, 30 insertions(+), 1 deletion(-)
On Thu, 7 Sep 2017, Martin Storsjö wrote:
Don't use _WIN64 to decide this, but check explicitly for i386,
and use _setjmp on other platforms.
This fixes compilation of code using setjmp on arm32.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/setjmp.h | 6 +++---
1 file changed, 3 ins
On Thu, 7 Sep 2017, Martin Storsjö wrote:
To actually produce the right kind of intended alias, use double
equals characters as in all other places.
This has been the same since it was initially added in
9ff1fefdadd4dec5826ff653cbac6f263bf47a72 though.
Signed-off-by: Martin Storsjö
---
mingw-
15 matches
Mail list logo