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
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
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.
---
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
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
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
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(),
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:
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,
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
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
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
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
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
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
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
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.
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
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ö
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
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
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
---
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 +
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
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,
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
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
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!
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
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ö
>
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ö
> ---
>
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)])],
> + [],
> +
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
>
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
>
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 +---
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
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
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
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
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
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
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
>
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.
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:
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
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++
46 matches
Mail list logo