[Mingw-w64-public] [PATCH 3/3] crt: Provide __p___argv in all msvcrt versions

2017-11-09 Thread Martin Storsjö
In msvcrt.dll, it only existed on i386. In the numbered msvcr* DLLs, it was present in all of them except msvcr80.dll for x86_64. Define __argv to use __p___argv(). This makes sure that code in libmingwex (getopt.c) that references __argv will work regardless of which msvcrt/ucrtbase it ends up

[Mingw-w64-public] [PATCH 2/3] headers: Hook up __argc and similar external variables for ucrtbase

2017-11-09 Thread Martin Storsjö
Not all the variables that were listed seem to be exported from ucrtbase though, so only hook up those that do exist. Signed-off-by: Martin Storsjö --- This was approved previously by JonY, but is rebased on top of an updated patch. --- mingw-w64-headers/crt/stdlib.h | 48

[Mingw-w64-public] [PATCH 1/3] headers: Restructure declarations of external variables like __argc

2017-11-09 Thread Martin Storsjö
This is in preparation for redefining these declarations for ucrtbase. Signed-off-by: Martin Storsjö --- I don't think anyone actually has commented on this one yet, but it's a prerequisite for the patch that adds the ucrtbase versions of them. ---

Re: [Mingw-w64-public] [PATCH] crt: Don't include the new *_dbg functions on x86

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Patch ok. Please go ahead. Thanks, Kai 2017-11-09 10:01 GMT+01:00 Martin Storsjö : > Prior to unification of msvcrt.def.in, neither 32 or 64 bit x86 > did export this function. In practice, they seem to have existed > since Vista. > > At this point, msvcrt.def.in should

Re: [Mingw-w64-public] [PATCH 2/3] headers: Hook up __argc and similar external variables for ucrtbase

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Patch ok. Please go ahead. Thanks, Kai 2017-11-09 9:59 GMT+01:00 Martin Storsjö : > Not all the variables that were listed seem to be exported from > ucrtbase though, so only hook up those that do exist. > > Signed-off-by: Martin Storsjö > --- > This was

Re: [Mingw-w64-public] Calling wprintf from a C++ program

2017-11-09 Thread Liu Hao
On 2017/11/9 15:46, David Lee wrote: Thanks for the reply. You are welcome. :> (1) Your observation seems to apply to the whole *wprintf() family (fwprintf(), swprintf(), etc), not just wprintf(). It seems so. I am not clear how libstdc++ is making use if these functions. If they didn't

Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Jacek Caban
Hello, On 11/9/17 11:10 AM, Martin Storsjö wrote: On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hmm, C99 support is pretty important for the gnu world.  Nevertheless patch ok. Please go ahead. Yup, I know. However, right now if you build with msvcrt.dll and use e.g. wprintf(),

[Mingw-w64-public] [PATCH] crt: Don't include the new *_dbg functions on x86

2017-11-09 Thread Martin Storsjö
Prior to unification of msvcrt.def.in, neither 32 or 64 bit x86 did export this function. In practice, they seem to have existed since Vista. At this point, msvcrt.def.in should preprocess into the exact same list of functions as prior to unification on both 32 and 64 bit x86. Signed-off-by:

Re: [Mingw-w64-public] [PATCH 1/3] headers: Restructure declarations of external variables like __argc

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Patch ok. Please go ahead. Thanks, Kai 2017-11-09 9:59 GMT+01:00 Martin Storsjö : > This is in preparation for redefining these declarations for ucrtbase. > > Signed-off-by: Martin Storsjö > --- > I don't think anyone actually has commented on this one yet,

Re: [Mingw-w64-public] [PATCH 0/7] Ucrtbase/__argv/__p___* functions

2017-11-09 Thread Kai Tietz via Mingw-w64-public
2017-11-09 9:18 GMT+01:00 Martin Storsjö : > On Thu, 9 Nov 2017, Jacek Caban wrote: > >> On 08.11.2017 23:19, Martin Storsjö wrote: >>> >>> - Fix getopt by using __p___argv there instead of __argv, as Jacek >>> suggested. In order to do this, I ended up cleaning up a few other

Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: Hello, On 11/9/17 11:10 AM, Martin Storsjö wrote: On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hmm, C99 support is pretty important for the gnu world.  Nevertheless patch ok. Please go ahead. Yup, I know. However, right now if you build

Re: [Mingw-w64-public] [PATCH 6/7] crt: Provide __p___argv in all msvcrt versions

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: On 08.11.2017 23:19, Martin Storsjö wrote: + // We have a fallback definition of __p___argv for msvcrt versions that + // lack it, so always declare it as available, but without _CRTIMP. + char ***__cdecl __p___argv(void); How about using

Re: [Mingw-w64-public] [PATCH 0/7] Ucrtbase/__argv/__p___* functions

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: On 08.11.2017 23:19, Martin Storsjö wrote: - Fix getopt by using __p___argv there instead of __argv, as Jacek suggested. In order to do this, I ended up cleaning up a few other inconsistencies surrounding the build of msvcr* dlls/defs while I was

Re: [Mingw-w64-public] [PATCH 3/7] crt: Only expose the __p___* functions in msvcrt.def on i386

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: On 08.11.2017 23:19, Martin Storsjö wrote: When cleaning up post-unification differences in 1035bed24e833ea5eb487c78f4f350ea48f31e8b, these were kept since I thought they wouldn't be an issue (and I thought they weren't really of much interest/use). For

[Mingw-w64-public] [PATCHv2 3/3] crt: Provide __p___argv in all msvcrt versions

2017-11-09 Thread Martin Storsjö
In msvcrt.dll, it only existed on i386. In the numbered msvcr* DLLs, it was present in all of them except msvcr80.dll for x86_64. Define __argv to use __p___argv(). This makes sure that code in libmingwex (getopt.c) that references __argv will work regardless of which msvcrt/ucrtbase it ends up

Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Hmm, C99 support is pretty important for the gnu world. Nevertheless patch ok. Please go ahead. Thanks, Kai 2017-11-09 10:04 GMT+01:00 Martin Storsjö : > When __USE_MINGW_ANSI_STDIO is defined, we still call the custom > implementation bundled in libmingwex. (Redirecting this

Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Martin Storsjö wrote: On Thu, 9 Nov 2017, Jacek Caban wrote: Hello, On 11/9/17 11:10 AM, Martin Storsjö wrote: On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hmm, C99 support is pretty important for the gnu world.  Nevertheless patch ok. Please go ahead.

Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Jacek Caban
On 11/9/17 1:08 PM, Martin Storsjö wrote: Just one detail: Note that supporting legacy behavior in this care is easy. One can achieve that with -D__USE_MINGW_ANSI_STDIO=0. Not quite - if you're in an environment that defaults to ucrtbase, you need to set

[Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Martin Storsjö
When __USE_MINGW_ANSI_STDIO is defined, we still call the custom implementation bundled in libmingwex. (Redirecting this case to use the ucrtbase functions with other options could be a future improvement.) This reduces the risk of issues when moving to ucrtbase. Signed-off-by: Martin Storsjö

Re: [Mingw-w64-public] [PATCHv2 3/3] crt: Provide __p___argv in all msvcrt versions

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Patch looks better now. Please go ahead. Thanks, Kai 2017-11-09 11:02 GMT+01:00 Martin Storsjö : > In msvcrt.dll, it only existed on i386. In the numbered msvcr* DLLs, > it was present in all of them except msvcr80.dll for x86_64. > > Define __argv to use __p___argv(). > > This

Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hmm, C99 support is pretty important for the gnu world. Nevertheless patch ok. Please go ahead. Yup, I know. However, right now if you build with msvcrt.dll and use e.g. wprintf(), you get the nonstandard behaviour unless you set

[Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library

2017-11-09 Thread Martin Storsjö
Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am | 20 mingw-w64-crt/configure.ac | 12 2 files changed, 32 insertions(+) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 04f4d82..72e0fdd 100644 ---

[Mingw-w64-public] [PATCH 1/2] headers: Allow setting the default __MSVCRT_VERSION__

2017-11-09 Thread 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ö --- mingw-w64-crt/Makefile.am | 2 +- mingw-w64-crt/crt/ucrtbase_compat.c | 1 +

[Mingw-w64-public] [PATCH 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Martin Storsjö
This makes sure that all code in libmingwex that refers to stderr etc will work correctly even if linked to ucrtbase. Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am | 121 +--- mingw-w64-crt/crt/ucrtbase_compat.c | 30

[Mingw-w64-public] [PATCH 2/2] crt: Stop building with -fno-builtin-fprintf

2017-11-09 Thread Martin Storsjö
Now that all references to stderr go via __acrt_iob_func, it doesn't matter if code in crt startup routines get optimized from fprintf into fwrite or fputc. This partially reverts 7cde6573. Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am | 4 1 file changed,

[Mingw-w64-public] [PATCH 2/2] headers: Always map e.g. time to _time32 or _time64 for ucrtbase

2017-11-09 Thread Martin Storsjö
ucrtbase doesn't have any function named plain 'time'. Force these to be remapped to the inline form even if inlining otherwise wouldn't be done. Make sure that we don't keep any non-inline declaration, because otherwise a caller that tries to take the function address would end up referring to

[Mingw-w64-public] [PATCH 1/2] crt: Don't add extra timezone related exports to ucrtbase.def

2017-11-09 Thread Martin Storsjö
These common parts from msvcrt-common.def.in don't belong in ucrtbase.def. Mark longjmp as DATA on X86 only, since we provide a wrapped version in misc/mingw_getsp.S, but only on X86. Signed-off-by: Martin Storsjö --- This didn't get any comments in the first large batch, no

Re: [Mingw-w64-public] [PATCH] crt: Don't include the new *_dbg functions on x86

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Patch ok. Please go ahead. Thanks, pushed // Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org!

Re: [Mingw-w64-public] [PATCHv2 3/3] crt: Provide __p___argv in all msvcrt versions

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Patch looks better now. Please go ahead. Thanks, these 3 pushed now. // Martin -- Check out the vibrant tech community on one of the world's most engaging

Re: [Mingw-w64-public] [PATCH 2/2] crt: Stop building with -fno-builtin-fprintf

2017-11-09 Thread Jacek Caban
On 09.11.2017 16:00, Martin Storsjö wrote: > Now that all references to stderr go via __acrt_iob_func, it doesn't > matter if code in crt startup routines get optimized from fprintf > into fwrite or fputc. > > This partially reverts 7cde6573. > > Signed-off-by: Martin Storsjö >

Re: [Mingw-w64-public] [PATCH 1/2] crt: Don't add extra timezone related exports to ucrtbase.def

2017-11-09 Thread Jacek Caban
On 09.11.2017 15:58, Martin Storsjö wrote: > These common parts from msvcrt-common.def.in don't belong in > ucrtbase.def. > > Mark longjmp as DATA on X86 only, since we provide a wrapped > version in misc/mingw_getsp.S, but only on X86. > > Signed-off-by: Martin Storsjö > --- >

Re: [Mingw-w64-public] [PATCH 1/2] headers: Allow setting the default __MSVCRT_VERSION__

2017-11-09 Thread Jacek Caban
Hi Martin, On 09.11.2017 15:59, Martin Storsjö wrote: > +AC_MSG_CHECKING([default __MSVCRT_VERSION__]) > +AC_ARG_WITH([default-msvcrt-version], > + [AS_HELP_STRING([--with-default-msvcrt-version=VER], > +[Default value of __MSVCRT_VERSION__ (default: 0x700)])], > + [], > +

Re: [Mingw-w64-public] [PATCH 2/2] headers: Always map e.g. time to _time32 or _time64 for ucrtbase

2017-11-09 Thread Jacek Caban
Hi Martin, Looks good to me. On 09.11.2017 15:58, Martin Storsjö wrote: > -#ifndef __CRT__NO_INLINE > +#if !defined(__CRT__NO_INLINE) || __MSVCRT_VERSION__ >= 0x1400 > +#if __MSVCRT_VERSION__ >= 0x1400 > +#define __TIME_INLINE __mingw_static_ovr > +#else > +#define __TIME_INLINE __CRT_INLINE >

Re: [Mingw-w64-public] [PATCH 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Jacek Caban
Hi Martin, On 09.11.2017 16:00, Martin Storsjö wrote: > This makes sure that all code in libmingwex that refers to stderr > etc will work correctly even if linked to ucrtbase. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/Makefile.am | 121 >

[Mingw-w64-public] [PATCHv2 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Martin Storsjö
This makes sure that all code in libmingwex that refers to stderr etc will work correctly even if linked to ucrtbase. Signed-off-by: Martin Storsjö --- Now with the new file included as well... --- mingw-w64-crt/Makefile.am | 121 +---

Re: [Mingw-w64-public] [PATCH 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: Hi Martin, On 09.11.2017 16:00, Martin Storsjö wrote: This makes sure that all code in libmingwex that refers to stderr etc will work correctly even if linked to ucrtbase. Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am

Re: [Mingw-w64-public] [PATCHv2 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Jacek Caban
Hi Martin, On 09.11.2017 20:33, Martin Storsjö wrote: > if !W32API > -lib32_DATA += lib32/libglut.a lib32/libmsvcp60.a lib32/libmsvcr80.a > lib32/libmsvcr90.a lib32/libmsvcr90d.a lib32/libmsvcr100.a \ > - lib32/libmsvcr110.a lib32/libmsvcr120.a > lib32/libmsvcr120d.a

Re: [Mingw-w64-public] [PATCHv2 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: Hi Martin, On 09.11.2017 20:33, Martin Storsjö wrote: if !W32API -lib32_DATA += lib32/libglut.a lib32/libmsvcp60.a lib32/libmsvcr80.a lib32/libmsvcr90.a lib32/libmsvcr90d.a lib32/libmsvcr100.a \ - lib32/libmsvcr110.a

Re: [Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Hmm, I would prefer to have a configure option. But nevertheless all libraries should be built regardless to this configure option, but under separate unique names. The configure option should just decide, which msvc*/ucrt library version should be copied as libmsvcrt.a library. 2017-11-09 15:59

Re: [Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hmm, I would prefer to have a configure option. But nevertheless all libraries should be built regardless to this configure option, but under separate unique names. The configure option should just decide, which msvc*/ucrt library

[Mingw-w64-public] [PATCHv3 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Martin Storsjö
This makes sure that all code in libmingwex that refers to stderr etc will work correctly even if linked to ucrtbase. Signed-off-by: Martin Storsjö --- Now with the new file included as well, and with the copypaste issues in Makefile.am fixed. --- mingw-w64-crt/Makefile.am

Re: [Mingw-w64-public] [PATCHv3 1/2] crt: Use __acrt_iob_func for accessing __iob in all msvcrt versions

2017-11-09 Thread Jacek Caban
On 09.11.2017 21:24, Martin Storsjö wrote: > This makes sure that all code in libmingwex that refers to stderr > etc will work correctly even if linked to ucrtbase. > > Signed-off-by: Martin Storsjö > --- > Now with the new file included as well, and with the copypaste issues >

Re: [Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library

2017-11-09 Thread Kai Tietz via Mingw-w64-public
Hmm, I am not really good at choosing nice names. But well, I would vote for something like libmsvcrt_os.a Cheers Kai 2017-11-09 22:42 GMT+01:00 Martin Storsjö : > On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote: > >> Hmm, I would prefer to have a configure option.

Re: [Mingw-w64-public] [PATCH 2/2] crt: Stop building with -fno-builtin-fprintf

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: On 09.11.2017 16:00, Martin Storsjö wrote: Now that all references to stderr go via __acrt_iob_func, it doesn't matter if code in crt startup routines get optimized from fprintf into fwrite or fputc. This partially reverts 7cde6573. Signed-off-by:

Re: [Mingw-w64-public] [PATCH 2/2] headers: Always map e.g. time to _time32 or _time64 for ucrtbase

2017-11-09 Thread Martin Storsjö
On Thu, 9 Nov 2017, Jacek Caban wrote: Hi Martin, Looks good to me. On 09.11.2017 15:58, Martin Storsjö wrote: -#ifndef __CRT__NO_INLINE +#if !defined(__CRT__NO_INLINE) || __MSVCRT_VERSION__ >= 0x1400 +#if __MSVCRT_VERSION__ >= 0x1400 +#define __TIME_INLINE __mingw_static_ovr +#else

Re: [Mingw-w64-public] Calling wprintf from a C++ program

2017-11-09 Thread David Lee
One more note. After some testing I found that: (1) If you write C++ code with mingw-w64 but you manage to NOT include any system C++ headers, __USE_MINGW_ANSI_STDIO will NOT be defined. (2) You might accidentally #include one without knowing. As an example: #include With mingw-w64, on g++