Re: [Mingw-w64-public] [PATCH] headers: Use asm() for redirecting time functions, instead of inline functions
Hi,
thanks for working on this and unifying this inlining issues. Looks good to me.
Thanks
Kai
Am Mi., 8. Mai 2024 um 14:23 Uhr schrieb Martin Storsjö :
>
> Prior to 1652e9241b5d8a5a779c6582b1c3c4f4a7cc66e5, the inline
> functions always were static. Due to reexporting such symbols
> in C++20 modules (for the C++23 std module), the reexported symbols
> must not be static, so the inline functions were changed
> from static inline to __mingw_ovr, which practically is static
> inline in C mode, but regular inline in C++ mode.
>
> By using regular inline in C++ mode, each use of the functions
> can (but doesn't need to) emit an external symbol for the
> inline function, and the callers may either call that function
> or inline the body of the function.
>
> This can have two potential issues; if different translation units
> are configured differently (with the _USE_32BIT_TIME_T define),
> but both use the same external symbol for it, the linker will only
> keep one of them (as they're both inline, and supposed to be the
> same). In practice, this is rare for _USE_32BIT_TIME_T though.
>
> Secondly, such an external symbol may conflict with the actual
> import library. Such a case was reported at
> https://github.com/mstorsjo/llvm-mingw/issues/427.
>
> (Practically, the issue there was that some built object files
> defined an external "_time" symbol, i.e. regular "time" with i386
> cdecl underscore prefix, from the non-static inline functions. The
> object also files reference _time32 with dllimport, which via the
> weak aliases produced by llvm-dlltool end up pulling in the
> __imp__time symbol, which also brings in a conflicting "_time" symbol.)
>
> In short - inline functions can be problematic. Where possible,
> it's less problematic to use asm(), via __MINGW_ASM_CALL(), to
> redirect calls directly towards the right function.
>
> This has a slight drawback, that this ends up calling the thunks
> (as the declarations lack dllimport), while we previously could
> inline the call directly to a dllimported function (avoiding the
> thunk, fetching the target address via the __imp_ prefixed symbol).
>
> We could, easily, add the dllimport attributes on these declarations,
> but that triggers a GCC bug for how those symbol names are mangled
> on i386, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114984. (The
> bug seems to be noted and mentioned as early as 2007, in
> https://sourceware.org/pipermail/cygwin/2007-February/154845.html,
> but it doesn't seem to have been fixed since.)
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-headers/crt/time.h | 62
> 1 file changed, 28 insertions(+), 34 deletions(-)
>
> diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
> index f8401903c..d94a9f619 100644
> --- a/mingw-w64-headers/crt/time.h
> +++ b/mingw-w64-headers/crt/time.h
> @@ -213,26 +213,20 @@ extern "C" {
>
> #if !defined (RC_INVOKED) && !defined (_INC_WTIME_INL)
> #define _INC_WTIME_INL
> - wchar_t *__cdecl _wctime(const time_t *)
> __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
> -#ifndef __CRT__NO_INLINE
> #ifndef _USE_32BIT_TIME_T
> - __CRT_INLINE wchar_t *__cdecl _wctime(const time_t *_Time) { return
> _wctime64(_Time); }
> + wchar_t *__cdecl _wctime(const time_t *_Time)
> __MINGW_ATTRIB_DEPRECATED_SEC_WARN __MINGW_ASM_CALL(_wctime64);
> #else
> - __CRT_INLINE wchar_t *__cdecl _wctime(const time_t *_Time) { return
> _wctime32(_Time); }
> + wchar_t *__cdecl _wctime(const time_t *_Time)
> __MINGW_ATTRIB_DEPRECATED_SEC_WARN __MINGW_ASM_CALL(_wctime32);
> #endif
> -#endif /* __CRT__NO_INLINE */
> #endif
>
> #if !defined (RC_INVOKED) && !defined (_INC_WTIME_S_INL)
> #define _INC_WTIME_S_INL
> - errno_t __cdecl _wctime_s(wchar_t *, size_t, const time_t *);
> -#ifndef __CRT__NO_INLINE
> #ifndef _USE_32BIT_TIME_T
> - __CRT_INLINE errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t
> _SizeInWords,const time_t *_Time) { return _wctime64_s
> (_Buffer,_SizeInWords,_Time); }
> + errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t _SizeInWords,const
> time_t *_Time) __MINGW_ASM_CALL(_wctime64_s);
> #else
> - __CRT_INLINE errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t
> _SizeInWords,const time_t *_Time) { return _wctime32_s
> (_Buffer,_SizeInWords,_Time); }
> + errno_t __cdecl _wctime_s (wchar_t *_Buffer,size_t _SizeInWords,const
> time_t *_Time) __MINGW_ASM_CALL(_wctime32_s);
> #endif
> -#endif /* __CRT__NO_INLINE */
> #endif
>
> #define _WTIME_DEFINED
> @@ -241,33 +235,33 @@ extern "C" {
> #ifndef RC_INVOKED
>
> #ifdef _USE_32BIT_TIME_T
> -__mingw_ovr time_t __CRTDECL time(time_t *_Time) { return _time32(_Time); }
> +time_t __CRTDECL time(time_t *_Time) __MINGW_ASM_CALL(_time32);
> #ifdef _UCRT
> -__mingw_ovr int __CRTDECL timespec_get(struct timespec* _Ts, int _Base) {
> return _timespec32_get((struct _timespec32*)_Ts, _Base); }
> -#endif
> -__mingw_ovr double __CRTDECL difftime(time_t _Time1,time_t _Time2) { return
> _d
Re: [Mingw-w64-public] [PATCH] crt: Implement the __stpcpy_chk function
Thanks! Am Fr., 14. Okt. 2022 um 15:24 Uhr schrieb Martin Storsjö : > > On Fri, 14 Oct 2022, Kai Tietz wrote: > > > Yes, look good to me. Wouldn't it make sense to add __mingww64_stpcpy > > function, so we could provide this function in an more compatible way? > > I don't see the direct need for it; mingw-w64 doesn't have it general, and > this status quo works for most projects (if they use it, they probe for > its existence and provide a replacement), so I don't see the potential > gain from optionally providing it. This seemed to be the general consensus > in https://github.com/msys2/MINGW-packages/issues/5803 too, FWIW. > > // Martin > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Implement the __stpcpy_chk function
Yes, look good to me. Wouldn't it make sense to add __mingww64_stpcpy function, so we could provide this function in an more compatible way? Thanks, Kai Am Fr., 14. Okt. 2022 um 14:16 Uhr schrieb LIU Hao : > > 在 2022/10/14 19:38, Martin Storsjö 写道: > > Initially, it may seem like this function might not be needed in any > > form, since mingw-w64 lacks the main stpcpy function. > > > > However, third party projects may contain their own implementation of > > the stpcpy function. When GCC sees a declaration of the stpcpy function, > > it assumes that it is legal to do optimizations on strcpy+strlen into > > stpcpy. > > > > When strcpy is wrapped with fortification wrappers, so that strcpy > > ends up calling __builtin___strcpy_chk (which then calls __strcpy_chk), > > GCC can also transform this into __builtin___stpcpy_chk, which can > > generate a call to __stpcpy_chk. > > > > GCC's libssp does provide an implementation of __stpcpy_chk, even if > > the platform itself lacks stpcpy. > > > > Therefore, mingw-w64-crt's implementation of the ssp routines also > > does need an implementation of __stpcpy_chk, even if it is hard > > to practically produce calls to it. > > > > This should fix one issue discussed at > > https://github.com/msys2/MINGW-packages/issues/5803#issuecomment-1276812143. > > > > Signed-off-by: Martin Storsjö > > --- > > mingw-w64-crt/Makefile.am | 2 +- > > mingw-w64-crt/ssp/stpcpy_chk.c | 19 +++ > > 2 files changed, 20 insertions(+), 1 deletion(-) > > create mode 100644 mingw-w64-crt/ssp/stpcpy_chk.c > > > > LGTM. Thanks. > > > -- > Best regards, > LIU Hao > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Hello, some of you might know Ray Donnelly. I have sad news about him. He still fights the cancer, but it seems he has lost the fight. So he stays right now in this hospice. Maybe y
GoFundMe zu unterstützen: https://gofund.me/83986499. Best regards, Kai Tietz ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Build the SEH inline assembly with clang 7
Patch is ok. Thanks, Kai We might could introduce a helper macro in _mingw_mac.h for it? 2018-08-14 13:55 GMT+02:00 Liu Hao : > 在 2018-08-14 19:21, Martin Storsjö 写道: >> Clang got support for the .rva assembler directive soon before >> the clang 7.0 release branch was made. >> >> This breaks use of mingw-w64 with older SVN snapshot versions of >> clang 7, if building with SEH enabled. However, most such users >> probably build with DWARF exception handling instead of SEH, since >> clang-bootstrapped environments have been missing other bits for >> SEH until recently. >> >> Signed-off-by: Martin Storsjö >> --- >> mingw-w64-crt/crt/crtexe.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> > > This patch looks good to me. > > > > -- > Best regards, > LH_Mouse > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: x86: Add missing clobbers in the cossin inline assembly
Thanks for fixing this. Please apply. Kai 2018-03-12 21:34 GMT+01:00 Martin Storsjö : > This fixes the function when built with clang. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/math/x86/cossin.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mingw-w64-crt/math/x86/cossin.c b/mingw-w64-crt/math/x86/cossin.c > index 0095daa..cb33405 100644 > --- a/mingw-w64-crt/math/x86/cossin.c > +++ b/mingw-w64-crt/math/x86/cossin.c > @@ -25,7 +25,7 @@ void sincos (double __x, double *p_sin, double *p_cos) > "jnz 2b\n\t" > "fstp %%st(1)\n\t" > "fsincos\n\t" > -"1:" : "=t" (c), "=u" (s) : "0" (__x)); > +"1:" : "=t" (c), "=u" (s) : "0" (__x) : "eax"); >*p_sin = (double) s; >*p_cos = (double) c; > } > @@ -47,7 +47,7 @@ void sincosf (float __x, float *p_sin, float *p_cos) > "jnz 2b\n\t" > "fstp %%st(1)\n\t" > "fsincos\n\t" > -"1:" : "=t" (c), "=u" (s) : "0" (__x)); > +"1:" : "=t" (c), "=u" (s) : "0" (__x) : "eax"); >*p_sin = (float) s; >*p_cos = (float) c; > } > @@ -69,7 +69,7 @@ void sincosl (long double __x, long double *p_sin, long > double *p_cos) > "jnz 2b\n\t" > "fstp %%st(1)\n\t" > "fsincos\n\t" > -"1:" : "=t" (c), "=u" (s) : "0" (__x)); > +"1:" : "=t" (c), "=u" (s) : "0" (__x) : "eax"); >*p_sin = s; >*p_cos = c; > } > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Use __attribute__((force_align_arg_pointer)) for aligning the stack on entry
Ok.
Thanks Kai
2018-03-11 23:29 GMT+01:00 Martin Storsjö :
> This attribute is available since GCC 4.2.
>
> The previous trick of using inline assembly for overriding the stack
> pointer behind the compiler's back isn't guaranteed to work.
>
> This fixes stack alignment on llvm/clang.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/crt/crtexe.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
> index 4542bfe..e390074 100644
> --- a/mingw-w64-crt/crt/crtexe.c
> +++ b/mingw-w64-crt/crt/crtexe.c
> @@ -221,6 +221,11 @@ int mainCRTStartup (void)
> }
>
> static
> +#if defined(__i386__) || defined(_X86_)
> +/* We need to make sure that we align the stack to 16 bytes for the sake of
> SSE
> + opts in main or in functions called main. */
> +__attribute__((force_align_arg_pointer))
> +#endif
> __declspec(noinline) int
> __tmainCRTStartup (void)
> {
> @@ -229,17 +234,6 @@ __tmainCRTStartup (void)
>WINBOOL inDoubleQuote = FALSE;
>memset (&StartupInfo, 0, sizeof (STARTUPINFO));
>
> -#if defined(__i386__) || defined(_X86_)
> - /* We need to make sure that this function is build with frame-pointer
> - and that we align the stack to 16 bytes for the sake of SSE ops in main
> - or in functions inlined into main. */
> - lpszCommandLine = (_TCHAR *) alloca (32);
> - memset (lpszCommandLine, 0xcc, 32);
> -#ifdef __GNUC__
> - asm __volatile__ ("andl $-16, %%esp" : : : "%esp");
> -#endif
> -#endif /* defined(__i386__) || defined(_X86_) */
> -
>if (mingw_app_type)
> GetStartupInfo (&StartupInfo);
>{
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Add "volatile" to all inline assembly snippets under math
Patch is ok.
Thanks,
Kai
2018-03-11 21:57 GMT+01:00 Martin Storsjö :
> On 32 bit x86, clang seems to miss loading input parameters based
> on asm constraints for inline assembly that uses the x87 floating
> registers, unless the snippet has got the volatile keyword.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/math/fabs.c| 2 +-
> mingw-w64-crt/math/fabsf.c | 2 +-
> mingw-w64-crt/math/fabsl.c | 2 +-
> mingw-w64-crt/math/modf.c| 4 ++--
> mingw-w64-crt/math/modff.c | 4 ++--
> mingw-w64-crt/math/modfl.c | 4 ++--
> mingw-w64-crt/math/sqrt.def.h| 10 +-
> mingw-w64-crt/math/x86/acosf.c | 3 ++-
> mingw-w64-crt/math/x86/acosl.c | 3 ++-
> mingw-w64-crt/math/x86/asinf.c | 3 ++-
> mingw-w64-crt/math/x86/asinl.c | 3 ++-
> mingw-w64-crt/math/x86/atan2.c | 2 +-
> mingw-w64-crt/math/x86/atan2f.c | 2 +-
> mingw-w64-crt/math/x86/atan2l.c | 2 +-
> mingw-w64-crt/math/x86/atanf.c | 3 ++-
> mingw-w64-crt/math/x86/atanl.c | 3 ++-
> mingw-w64-crt/math/x86/exp.def.h | 3 ++-
> mingw-w64-crt/math/x86/fmod.c| 3 ++-
> mingw-w64-crt/math/x86/fmodf.c | 3 ++-
> mingw-w64-crt/math/x86/fmodl.c | 3 ++-
> mingw-w64-crt/math/x86/logb.c| 3 ++-
> mingw-w64-crt/math/x86/logbf.c | 3 ++-
> mingw-w64-crt/math/x86/logbl.c | 3 ++-
> mingw-w64-crt/math/x86/pow.def.h | 6 +++---
> 24 files changed, 46 insertions(+), 33 deletions(-)
>
> diff --git a/mingw-w64-crt/math/fabs.c b/mingw-w64-crt/math/fabs.c
> index 2011378..a663711 100644
> --- a/mingw-w64-crt/math/fabs.c
> +++ b/mingw-w64-crt/math/fabs.c
> @@ -14,7 +14,7 @@ fabs (double x)
> #elif defined(__i386__) || defined(_X86_)
>double res = 0.0;
>
> - asm ("fabs;" : "=t" (res) : "0" (x));
> + asm volatile ("fabs;" : "=t" (res) : "0" (x));
>return res;
> #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__arm__) ||
> defined(_ARM_) || defined(__aarch64__) || defined(_ARM64_) */
> }
> diff --git a/mingw-w64-crt/math/fabsf.c b/mingw-w64-crt/math/fabsf.c
> index e8520d5..e7e9d8f 100644
> --- a/mingw-w64-crt/math/fabsf.c
> +++ b/mingw-w64-crt/math/fabsf.c
> @@ -12,7 +12,7 @@ fabsf (float x)
>return __builtin_fabsf (x);
> #elif defined(__i386__) || defined(_X86_)
>float res = 0.0F;
> - asm ("fabs;" : "=t" (res) : "0" (x));
> + asm volatile ("fabs;" : "=t" (res) : "0" (x));
>return res;
> #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__arm__) ||
> defined(_ARM_) || defined(__aarch64__) || defined(_ARM64_) */
> }
> diff --git a/mingw-w64-crt/math/fabsl.c b/mingw-w64-crt/math/fabsl.c
> index 20b8b22..1df48cf 100644
> --- a/mingw-w64-crt/math/fabsl.c
> +++ b/mingw-w64-crt/math/fabsl.c
> @@ -10,7 +10,7 @@ fabsl (long double x)
> {
> #if defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) ||
> defined(_X86_)
>long double res = 0.0L;
> - asm ("fabs;" : "=t" (res) : "0" (x));
> + asm volatile ("fabs;" : "=t" (res) : "0" (x));
>return res;
> #elif defined(__arm__) || defined(_ARM_) || defined(__aarch64__) ||
> defined(_ARM64_)
>return __builtin_fabsl (x);
> diff --git a/mingw-w64-crt/math/modf.c b/mingw-w64-crt/math/modf.c
> index f8ba64e..d262309 100644
> --- a/mingw-w64-crt/math/modf.c
> +++ b/mingw-w64-crt/math/modf.c
> @@ -13,7 +13,7 @@ modf (double value, double* iptr)
>double int_part = 0.0;
>/* truncate */
> #if defined(_AMD64_) || defined(__x86_64__)
> - asm ("subq $8, %%rsp\n"
> + asm volatile ("subq $8, %%rsp\n"
> "fnstcw 4(%%rsp)\n"
> "movzwl 4(%%rsp), %%eax\n"
> "orb $12, %%ah\n"
> @@ -23,7 +23,7 @@ modf (double value, double* iptr)
> "fldcw 4(%%rsp)\n"
> "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
> #elif defined(_X86_) || defined(__i386__)
> - asm ("push %%eax\n\tsubl $8, %%esp\n"
> + asm volatile ("push %%eax\n\tsubl $8, %%esp\n"
> "fnstcw 4(%%esp)\n"
> "movzwl 4(%%esp), %%eax\n"
> "orb $12, %%ah\n"
> diff --git a/mingw-w64-crt/math/modff.c b/mingw-w64-crt/math/modff.c
> index 2c4de3e..dcf19cf 100644
> --- a/mingw-w64-crt/math/modff.c
> +++ b/mingw-w64-crt/math/modff.c
> @@ -14,7 +14,7 @@ modff (float value, float* iptr)
>/* truncate */
>/* truncate */
> #if defined(_AMD64_) || defined(__x86_64__)
> - asm ("subq $8, %%rsp\n"
> + asm volatile ("subq $8, %%rsp\n"
> "fnstcw 4(%%rsp)\n"
> "movzwl 4(%%rsp), %%eax\n"
> "orb $12, %%ah\n"
> @@ -24,7 +24,7 @@ modff (float value, float* iptr)
> "fldcw 4(%%rsp)\n"
> "addq $8, %%rsp\n" : "=t" (int_part) : "0" (value) : "eax"); /* round */
> #elif defined(_X86_) || defined(__i386__)
> - asm ("push %%eax\n\tsubl $8, %%esp\n"
> + asm volatile ("push %%eax\n\tsubl $8, %%esp\n"
> "fnstcw 4(%%esp)\n"
> "movzwl 4(%%esp), %%eax\n"
> "orb $12, %%ah\n"
> diff --git a/mingw-w64-crt/math/modfl.c b/mingw-w64-crt/math/modfl.c
> index ef1ab16..33593e6 100644
> --- a/mingw-w64-crt/math/modfl.c
> +++ b/mingw-w64-crt/ma
Re: [Mingw-w64-public] [PATCH] uianimation.idl: Added missing constants.
Patch is ok. Thanks, Kai 2018-02-27 23:23 GMT+01:00 Jacek Caban : > > Based on patch by Ruslan Garipov. > > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/uianimation.idl | 6 ++ > 1 file changed, 6 insertions(+) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Temporarily undefine _Bool when typedeffing std::_Bool
Ok, thanks.
Cheers,
Kai
2018-02-23 11:02 GMT+01:00 Martin Storsjö :
> This fixes building the following with libc++:
>
> #include
> #include
>
> With libc++, yvals.h is implicitly included by anything that includes
> locales (via xlocinfo.h).
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-headers/crt/yvals.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mingw-w64-headers/crt/yvals.h b/mingw-w64-headers/crt/yvals.h
> index 70593c4..15130e4 100644
> --- a/mingw-w64-headers/crt/yvals.h
> +++ b/mingw-w64-headers/crt/yvals.h
> @@ -163,9 +163,12 @@
> #define _Restrict __restrict__
>
> #ifdef __cplusplus
> +#pragma push_macro("_Bool")
> +#undef _Bool
> _STD_BEGIN
> typedef bool _Bool;
> _STD_END
> +#pragma pop_macro("_Bool")
> #endif
>
> #define _LONGLONG /* __MINGW_EXTENSION */ __int64
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Allow sleeping for over a second with usleep
2018-02-23 10:56 GMT+01:00 Martin Storsjö : > On Fri, 23 Feb 2018, Kai Tietz via Mingw-w64-public wrote: > >> Patch looks fine beside one nit. The behavior above 4294967 seconds >> seems to be pretty unexpected, isn't it? > > > Well since the useconds_t parameter is a typedef for unsigned int, I > wouldn't think that callers expect to be able to sleep that long anyway. So > all possible input values (the values between 0 and UINT32_MAX) should work > just fine when divided by 1000 and passed to Sleep, no? > > // Martin True, as long as useconds_t is 32 bits wide So patch is ok. Thanks, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Allow sleeping for over a second with usleep
Patch looks fine beside one nit. The behavior above 4294967 seconds
seems to be pretty unexpected, isn't it?
Cheers,
Kai
2018-02-22 22:17 GMT+01:00 Martin Storsjö :
> Even though the POSIX spec of usleep says that the argument shall
> be less than one million. Most unixes allow it and sleeps for over a
> second if requested (in practice, at least on Linux/glibc and macOS).
>
> Prefer matching other actual implementations (which ignore this
> aspect of the POSIX spec) instead of following the spec strictly.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/misc/mingw_usleep.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/mingw-w64-crt/misc/mingw_usleep.c
> b/mingw-w64-crt/misc/mingw_usleep.c
> index 2b2dc32..8246e0b 100644
> --- a/mingw-w64-crt/misc/mingw_usleep.c
> +++ b/mingw-w64-crt/misc/mingw_usleep.c
> @@ -10,9 +10,7 @@ int __cdecl usleep (useconds_t);
> int __cdecl
> usleep (useconds_t us)
> {
> - if (us >= 100)
> -return EINVAL;
> - else if (us != 0)
> + if (us != 0)
> Sleep (us / 1000);
>
>return 0;
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] yvals.h: Don't create a _Bool typedef if a macro already exists
hmm, ok. But it might be better to temporary undefine _Bool via 'push_macro/pop_macro' pragma? Kai 2018-02-23 10:20 GMT+01:00 Martin Storsjö : > From: Hugo Beauzée-Luyssen > > This fixes building the following with libc++: > > #include > #include > > With libc++, yvals.h is implicitly included by anything that includes > locales (via xlocinfo.h). > > Signed-off-by: Martin Storsjö > --- > mingw-w64-headers/crt/yvals.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mingw-w64-headers/crt/yvals.h b/mingw-w64-headers/crt/yvals.h > index 70593c4..98b6921 100644 > --- a/mingw-w64-headers/crt/yvals.h > +++ b/mingw-w64-headers/crt/yvals.h > @@ -163,10 +163,12 @@ > #define _Restrict __restrict__ > > #ifdef __cplusplus > +#ifndef _Bool > _STD_BEGIN > typedef bool _Bool; > _STD_END > #endif > +#endif > > #define _LONGLONG /* __MINGW_EXTENSION */ __int64 > #define _ULONGLONG /* __MINGW_EXTENSION */ unsigned __int64 > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Updated widl to Wine 3.0-rc2 version.
Hey Jacek, sorry for answering this late. I have no objections to get in synch with Wine's upstream version. As long as midl isn't open sourced, and there is a ported version of it for none-windows world too, we will stick to the Wine version for sure. Thanks, Kai 2017-12-18 19:27 GMT+01:00 Jacek Caban : > We were unable to do that for a long time, because of additional > mingw-w64 patches that were committed on top of upstream version. Those > patches started implementing winrt features, but were never finished > (and were never compatible with midl). I implemented some of those in > midl compatible way in upstream Wine, but also never finished. Right now > it's enough for simple IDLs like: > https://source.winehq.org/git/wine.git/blob/HEAD:/include/windows.foundation.idl > > winrt aside, there are quite a few changes that mingw-w64 version is > missing and it's apparently starting to cause problems. > > That said, I propose to use upstream Wine upstream version and resurrect > import script in the tree. Dropped patches (needed for some winrt IDLs) > are easy to get from Git (just use a commit prior to this one). We could > even create a separated branch for that, if desired. > > Signed-off-by: Jacek Caban > --- > mingw-w64-tools/widl/VERSION|2 +- > mingw-w64-tools/widl/configure | 20 +- > mingw-w64-tools/widl/include/basetsd.h |6 +- > mingw-w64-tools/widl/include/guiddef.h | 11 + > mingw-w64-tools/widl/include/libloaderapi.h | 36 + > mingw-w64-tools/widl/include/winbase.h | 436 ++- > mingw-w64-tools/widl/include/windef.h | 33 +- > mingw-w64-tools/widl/include/winerror.h | 218 ++ > mingw-w64-tools/widl/include/winnls.h | 93 +- > mingw-w64-tools/widl/include/winnt.h| 927 +- > mingw-w64-tools/widl/include/winnt.rh |3 + > mingw-w64-tools/widl/src/client.c |6 +- > mingw-w64-tools/widl/src/expr.c | 14 +- > mingw-w64-tools/widl/src/header.c | 745 ++--- > mingw-w64-tools/widl/src/header.h | 11 +- > mingw-w64-tools/widl/src/parser.h |3 + > mingw-w64-tools/widl/src/parser.l | 91 +- > mingw-w64-tools/widl/src/parser.tab.c | > ++- > mingw-w64-tools/widl/src/parser.tab.h | 125 +- > mingw-w64-tools/widl/src/parser.y | 236 +- > mingw-w64-tools/widl/src/parser.yy.c| 939 +++--- > mingw-w64-tools/widl/src/port/getopt.c |2 + > mingw-w64-tools/widl/src/proxy.c| 14 +- > mingw-w64-tools/widl/src/typegen.c | 80 +- > mingw-w64-tools/widl/src/typelib.c |3 - > mingw-w64-tools/widl/src/typelib_struct.h |2 +- > mingw-w64-tools/widl/src/typetree.c | 86 +- > mingw-w64-tools/widl/src/typetree.h | 17 +- > mingw-w64-tools/widl/src/widl.c | 31 +- > mingw-w64-tools/widl/src/widl.h |3 +- > mingw-w64-tools/widl/src/widltypes.h| 32 +- > mingw-w64-tools/widl/src/wpp/ppl.l | 46 +- > mingw-w64-tools/widl/src/wpp/ppl.yy.c | 308 +- > mingw-w64-tools/widl/src/wpp/ppy.tab.c | 1992 ++-- > mingw-w64-tools/widl/src/wpp/ppy.tab.h | 142 +- > mingw-w64-tools/widl/src/wpp/preproc.c | 13 +- > mingw-w64-tools/widl/src/wpp/wpp.c |8 +- > mingw-w64-tools/widl/src/wpp/wpp_private.h |2 +- > mingw-w64-tools/widl/src/write_msft.c | 133 +- > mingw-w64-tools/widl/wine-import.sh | 41 + > 40 files changed, 6573 insertions(+), 4781 deletions(-) > create mode 100644 mingw-w64-tools/widl/include/libloaderapi.h > create mode 100755 mingw-w64-tools/widl/wine-import.sh > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] ucrtbase: Map the (_)strcmpi function to _stricmp
Patch is ok. Thanks, Kai 2018-02-06 23:17 GMT+01:00 Martin Storsjö : > When using GNU binutils, the function aliases won't work transitively, > i.e. the strcmpi == _strcmpi alias in msvcrt-common.def.in won't > use the second alias of _strcmpi == _stricmp in ucrtbase.def.in but > will instead end up with an import of the nonexistent function > _strcmpi. Therefore add an ifdef in msvcrt-common.def and add two > aliases in ucrtbase.def.in. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++ > mingw-w64-crt/lib-common/ucrtbase.def.in | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in > b/mingw-w64-crt/def-include/msvcrt-common.def.in > index c76bc6a..364e440 100644 > --- a/mingw-w64-crt/def-include/msvcrt-common.def.in > +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in > @@ -79,7 +79,9 @@ ADD_UNDERSCORE(spawnve) > ADD_UNDERSCORE(spawnvp) > ADD_UNDERSCORE(spawnvpe) > ;stat) > +#ifndef UCRTBASE > ADD_UNDERSCORE(strcmpi) > +#endif > ADD_UNDERSCORE(strdup) > ADD_UNDERSCORE(stricmp) > ADD_UNDERSCORE(stricoll) > diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in > b/mingw-w64-crt/lib-common/ucrtbase.def.in > index 8ca560a..4ca4e92 100644 > --- a/mingw-w64-crt/lib-common/ucrtbase.def.in > +++ b/mingw-w64-crt/lib-common/ucrtbase.def.in > @@ -1944,6 +1944,7 @@ _stat64 > _stat64i32 > _statusfp > F_I386(_statusfp2) > +_strcmpi == _stricmp > _strcoll_l > _strdate > _strdate_s > @@ -2529,6 +2530,7 @@ strcat > strcat_s > strchr > strcmp > +strcmpi == _stricmp > strcoll > strcpy > strcpy_s > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] wine-import.sh: Run autoconf after updating widl version.
Ok. Thanks, Kai 2018-02-06 11:53 GMT+01:00 Jacek Caban : > > This reverts 9b27e7e9ce13d05de3527878031e47cfe6eca06b. We update VERSION > file to Wine version, which is imported into configure script. > > Signed-off-by: Jacek Caban > --- > mingw-w64-tools/widl/wine-import.sh | 1 + > 1 file changed, 1 insertion(+) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] include/usbspec.h: Update to newest.
Patch is ok. Thanks, Kai 2018-01-29 11:52 GMT+01:00 Liu Hao : > On 2018/1/29 18:37, Liu Hao wrote: >> The definitions of `struct _USB_DEVICE_CAPABILITY_BILLBOARD_DESCRIPTOR` >> and `typedef struct >> _USB_SUPERSPEEDPLUS_ISOCH_ENDPOINT_COMPANION_DESCRIPTOR` got moved >> upwards to match their original order in from Win10 SDK >> 10.0.16299. >> > > Sorry the second patch was dropped. > > -- > Best regards, > LH_Mouse > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] include/usbioctl.h: Add required headers for `__C89_NAMELESS` and Windows data types.
Hey, why you include _mingw_mac.h before including minwindef.h ? This seems to be superflous. The header mingwindef.h includes already _mingw.h, which includes for sure _mingw_mac.h too. Te patch is ok with that change. Thanks, Kai 2018-01-29 11:36 GMT+01:00 Liu Hao : > This caused trouble when was included after . > > Reference: > https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/usbioctl/ne-usbioctl-_usb_connection_status > Signed-off-by: Liu Hao > > > -- > Best regards, > LH_Mouse > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: Fix prototype of `pthread_attr_{getstackaddr, getschedpolicy}`.
Hey, patch is ok. Please go ahead and apply. Thanks, Kai 2018-01-13 13:27 GMT+01:00 Liu Hao : > The attached patch adds `const` qualifiers that were missing. > > -- > Best regards, > LH_Mouse > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf("%zu") format warnings
Hello, it is a common, but nevertheless wrong assumption, that %z formatter is compatible for different runtimes. Especially msvcrt is all but C99 compatible. If you have enabled the use our C99 compatible printf/scanf implementation via the __USE_MINGW_ANSI_STDIO macro, then you will see that %z will work. To write portable code you can use the 'PRI/SCN' defines from inttypes.h header. Kai 2018-01-25 16:27 GMT+01:00 lemonsqueeze : > Hi, > > I'm looking for a portable way to print a size_t. > I thought "%zu" was the recommended way to do it, but I'm getting unknown > format warnings when printf() is called with "%zu". > > I guess i can use something like %llu instead but shouldn't this work in C99 > mode really ? (must be missing something here...) > > Cheers > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 4/4] dwrite_3.h: Added new header file.
Ok. Thanks, Kai 2018-01-22 19:00 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/dwrite_3.h | 587 > +++ > 1 file changed, 587 insertions(+) > create mode 100644 mingw-w64-headers/include/dwrite_3.h > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 3/4] dwrite1_1.h: Added DWRITE_PANOSE declaration.
Hmm, ok. Shouldn't we special case unnamed union/struct? Kai 2018-01-22 19:00 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/dwrite_1.h | 53 > > 1 file changed, 53 insertions(+) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/4] dcommon.h: Moved more declarations to dcommon.h.
Patch is ok. Kai 2018-01-22 19:00 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/d2d1_1.h | 1 - > mingw-w64-headers/include/d2dbasetypes.h | 9 - > mingw-w64-headers/include/dcommon.h | 22 ++ > 3 files changed, 22 insertions(+), 10 deletions(-) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/4] dwrite.h: Added DWRITE_DECLARE_INTERFACE define.
Patch is ok. Thanks, Kai 2018-01-22 19:00 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/dwrite.h | 4 > 1 file changed, 4 insertions(+) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stdio.h: Don't use ms_* and gnu_* format attributes on clang.
Patch is ok. But this is indeed problematic that clang doesn't support different scanf/printf warning API. For C99 printf/canf formatter diagnostic the produced warnings will be wrong for this compiler. Thanks Kai 2018-01-21 12:15 GMT+01:00 Martin Storsjö : > On Sun, 21 Jan 2018, Jacek Caban wrote: > >> clang doesn't support it, so it emits tons of warnings. >> >> Signed-off-by: Jacek Caban >> --- >> mingw-w64-headers/crt/stdio.h | 21 + >> 1 file changed, 13 insertions(+), 8 deletions(-) > > > LGTM > > // Martin > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Use volatile argument for __buildbittesti-based functions.
Patch is ok. Thanks, Kai 2018-01-19 18:38 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/psdk_inc/intrin-impl.h | 83 > > 1 file changed, 41 insertions(+), 42 deletions(-) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Map more stdio functions to their counterparts in ucrtbase
Hello,
patch is ok. Please go ahead and apply.
Thanks (and a happy new year for you),
Kai
2018-01-08 15:51 GMT+01:00 Martin Storsjö :
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-headers/crt/sec_api/stdio_s.h | 655
> +++-
> mingw-w64-headers/crt/sec_api/wchar_s.h | 199 +-
> mingw-w64-headers/crt/wchar.h | 280 +-
> 3 files changed, 1116 insertions(+), 18 deletions(-)
>
> diff --git a/mingw-w64-headers/crt/sec_api/stdio_s.h
> b/mingw-w64-headers/crt/sec_api/stdio_s.h
> index 092f337..c14427a 100644
> --- a/mingw-w64-headers/crt/sec_api/stdio_s.h
> +++ b/mingw-w64-headers/crt/sec_api/stdio_s.h
> @@ -26,8 +26,449 @@ extern "C" {
> #ifndef _STDIO_S_DEFINED
> #define _STDIO_S_DEFINED
>_CRTIMP errno_t __cdecl clearerr_s(FILE *_File);
> - int __cdecl fprintf_s(FILE *_File,const char *_Format,...);
> +
>size_t __cdecl fread_s(void *_DstBuf,size_t _DstSize,size_t
> _ElementSize,size_t _Count,FILE *_File);
> +
> +#if __MSVCRT_VERSION__ >= 0x1400
> + int __cdecl __stdio_common_vsprintf_s(unsigned __int64 _Options, char
> *_Str, size_t _Len, const char *_Format, _locale_t _Locale, va_list _ArgList);
> + int __cdecl __stdio_common_vsprintf_p(unsigned __int64 _Options, char
> *_Str, size_t _Len, const char *_Format, _locale_t _Locale, va_list _ArgList);
> + int __cdecl __stdio_common_vsnprintf_s(unsigned __int64 _Options, char
> *_Str, size_t _Len, size_t _MaxCount, const char *_Format, _locale_t _Locale,
> va_list _ArgList);
> + int __cdecl __stdio_common_vfprintf_s(unsigned __int64 _Options, FILE
> *_File, const char *_Format, _locale_t _Locale, va_list _ArgList);
> + int __cdecl __stdio_common_vfprintf_p(unsigned __int64 _Options, FILE
> *_File, const char *_Format, _locale_t _Locale, va_list _ArgList);
> +
> + __mingw_ovr int __cdecl _vfscanf_s_l(FILE *_File, const char *_Format,
> _locale_t _Locale, va_list _ArgList)
> + {
> +return __stdio_common_vfscanf(UCRTBASE_SCANF_SECURECRT, _File, _Format,
> _Locale, _ArgList);
> + }
> + __mingw_ovr int __cdecl _fscanf_s_l(FILE *_File, const char *_Format,
> _locale_t _Locale, ...)
> + {
> +__builtin_va_list _ArgList;
> +int _Ret;
> +__builtin_va_start(_ArgList, _Locale);
> +_Ret = _vfscanf_s_l(_File, _Format, _Locale, _ArgList);
> +__builtin_va_end(_ArgList);
> +return _Ret;
> + }
> + __mingw_ovr int __cdecl _scanf_s_l(const char *_Format, _locale_t _Locale
> ,...)
> + {
> +__builtin_va_list _ArgList;
> +int _Ret;
> +__builtin_va_start(_ArgList, _Locale);
> +_Ret = _vfscanf_s_l(stdin, _Format, _Locale, _ArgList);
> +__builtin_va_end(_ArgList);
> +return _Ret;
> + }
> +
> + __mingw_ovr int __cdecl _vfscanf_l(FILE *_File, const char *_Format,
> _locale_t _Locale, va_list _ArgList)
> + {
> +return __stdio_common_vfscanf(0, _File, _Format, _Locale, _ArgList);
> + }
> + __mingw_ovr int __cdecl _fscanf_l(FILE *_File, const char *_Format,
> _locale_t _Locale, ...)
> + {
> +__builtin_va_list _ArgList;
> +int _Ret;
> +__builtin_va_start(_ArgList, _Locale);
> +_Ret = _vfscanf_l(_File, _Format, _Locale, _ArgList);
> +__builtin_va_end(_ArgList);
> +return _Ret;
> + }
> + __mingw_ovr int __cdecl _scanf_l(const char *_Format, _locale_t _Locale,
> ...)
> + {
> +__builtin_va_list _ArgList;
> +int _Ret;
> +__builtin_va_start(_ArgList, _Locale);
> +_Ret = _vfscanf_l(stdin, _Format, _Locale, _ArgList);
> +__builtin_va_end(_ArgList);
> +return _Ret;
> + }
> +
> + __mingw_ovr int __cdecl _vsscanf_s_l(const char *_Src, const char
> *_Format, _locale_t _Locale, va_list _ArgList)
> + {
> +return __stdio_common_vsscanf(UCRTBASE_SCANF_SECURECRT, _Src,
> (size_t)-1, _Format, _Locale, _ArgList);
> + }
> + __mingw_ovr int __cdecl vsscanf_s(const char *_Src, const char *_Format,
> va_list _ArgList)
> + {
> +return _vsscanf_s_l(_Src, _Format, NULL, _ArgList);
> + }
> + __mingw_ovr int __cdecl _sscanf_s_l(const char *_Src, const char *_Format,
> _locale_t _Locale, ...)
> + {
> +__builtin_va_list _ArgList;
> +int _Ret;
> +__builtin_va_start(_ArgList, _Locale);
> +_Ret = _vsscanf_s_l(_Src, _Format, _Locale, _ArgList);
> +__builtin_va_end(_ArgList);
> +return _Ret;
> + }
> + __mingw_ovr int __cdecl sscanf_s(const char *_Src, const char *_Format,
> ...)
> + {
> +__builtin_va_list _ArgList;
> +int _Ret;
> +__builtin_va_start(_ArgList, _Format);
> +_Ret = _vsscanf_s_l(_Src, _Format, NULL, _ArgList);
> +__builtin_va_end(_ArgList);
> +return _Ret;
> + }
> +
> + __mingw_ovr int __cdecl _vsscanf_l(const char *_Src, const char *_Format,
> _locale_t _Locale, va_list _ArgList)
> + {
> +return __stdio_common_vsscanf(0, _Src, (size_t)-1, _Format, _Locale,
> _ArgList);
> + }
> + __mingw_ovr int __cdecl _sscanf_l(const char *_Src, const char *_Format,
> _locale_t _Locale, ...)
> + {
> +__builtin_va_list _ArgList;
>
Re: [Mingw-w64-public] [PATCH] headers: Remove an empty dxgi1_6.h
Ok. Pease go ahead- Thanks, Kai 2017-12-15 22:30 GMT+01:00 Martin Storsjö : > This was added at the same time as a bunch of non-empty headers > (and a non-empty dxgi1_6.idl) in aa6ab47929a9cac6897f38e630ce0bb88458e288; > this empty header seems to have been the result of an error. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-headers/direct-x/include/dxgi1_6.h | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > delete mode 100644 mingw-w64-headers/direct-x/include/dxgi1_6.h > > diff --git a/mingw-w64-headers/direct-x/include/dxgi1_6.h > b/mingw-w64-headers/direct-x/include/dxgi1_6.h > deleted file mode 100644 > index e69de29..000 > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Provide fallback implementations of __p__acmdln/__p__wcmdln
Hello Martin,
patch is ok. Please go ahead and commit, if Jacek has no objections.
Thanks,
Kai
2017-11-28 8:41 GMT+01:00 Martin Storsjö :
> This is necessary for msvcrt.dll on x86_64 (and arm and arm64) and
> msvcr80.dll on x86_64.
>
> This fixes building for x86_64 with msvcrt.dll since
> 9a2f3f1ca12ea76546812142f91385b3d4a374c9.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/Makefile.am| 16
> mingw-w64-crt/misc/__p__acmdln.c | 18 ++
> mingw-w64-crt/misc/__p__wcmdln.c | 18 ++
> 3 files changed, 48 insertions(+), 4 deletions(-)
> create mode 100644 mingw-w64-crt/misc/__p__acmdln.c
> create mode 100644 mingw-w64-crt/misc/__p__wcmdln.c
>
> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
> index bec76e2..6812a5e 100644
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -226,19 +226,27 @@ src_msvcrt32=\
>
> src_msvcrt64=\
>$(src_msvcrt) \
> - misc/__p___argv.c
> + misc/__p___argv.c \
> + misc/__p__acmdln.c \
> + misc/__p__wcmdln.c
>
> src_msvcrtarm32=\
>$(src_msvcrt) \
> - misc/__p___argv.c
> + misc/__p___argv.c \
> + misc/__p__acmdln.c \
> + misc/__p__wcmdln.c
>
> src_msvcrtarm64=\
>$(src_msvcrt) \
> - misc/__p___argv.c
> + misc/__p___argv.c \
> + misc/__p__acmdln.c \
> + misc/__p__wcmdln.c
>
> src_msvcr80_64=\
>$(src_msvcrt_common) \
> - misc/__p___argv.c
> + misc/__p___argv.c \
> + misc/__p__acmdln.c \
> + misc/__p__wcmdln.c
>
> # These mingwex sources are target independent:
> src_libmingwex=\
> diff --git a/mingw-w64-crt/misc/__p__acmdln.c
> b/mingw-w64-crt/misc/__p__acmdln.c
> new file mode 100644
> index 000..14e3868
> --- /dev/null
> +++ b/mingw-w64-crt/misc/__p__acmdln.c
> @@ -0,0 +1,18 @@
> +/**
> + * This file has no copyright assigned and is placed in the Public Domain.
> + * This file is part of the mingw-w64 runtime package.
> + * No warranty is given; refer to the file DISCLAIMER.PD within this package.
> + */
> +
> +#include <_mingw.h>
> +
> +extern char ** __MINGW_IMP_SYMBOL(_acmdln);
> +
> +char **__cdecl __p__acmdln(void);
> +char **__cdecl __p__acmdln(void)
> +{
> +return __MINGW_IMP_SYMBOL(_acmdln);
> +}
> +
> +typedef char **__cdecl (*_f__p__acmdln)(void);
> +_f__p__acmdln __MINGW_IMP_SYMBOL(__p__acmdln) = __p__acmdln;
> diff --git a/mingw-w64-crt/misc/__p__wcmdln.c
> b/mingw-w64-crt/misc/__p__wcmdln.c
> new file mode 100644
> index 000..f343904
> --- /dev/null
> +++ b/mingw-w64-crt/misc/__p__wcmdln.c
> @@ -0,0 +1,18 @@
> +/**
> + * This file has no copyright assigned and is placed in the Public Domain.
> + * This file is part of the mingw-w64 runtime package.
> + * No warranty is given; refer to the file DISCLAIMER.PD within this package.
> + */
> +
> +#include
> +
> +extern wchar_t ** __MINGW_IMP_SYMBOL(_wcmdln);
> +
> +wchar_t **__cdecl __p__wcmdln(void);
> +wchar_t **__cdecl __p__wcmdln(void)
> +{
> +return __MINGW_IMP_SYMBOL(_wcmdln);
> +}
> +
> +typedef wchar_t **__cdecl (*_f__p__wcmdln)(void);
> +_f__p__wcmdln __MINGW_IMP_SYMBOL(__p__wcmdln) = __p__wcmdln;
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat symbols aren't autoexported
Martin,
patch looks ok. Be careful about the static symbol in custom section
that it is actually present in a finally linked version. Sometimes
gcc thinks ... that it can optimize away such static symbols. I had
to introduce for that dummy references to such symbols in the past.
See crt/* folder for that.
Cheers,
Kai
2017-11-23 10:43 GMT+01:00 Martin Storsjö :
> When linking a DLL without using dllexport attributes or a def
> file, all global symbols are exported, unless they are excluded
> for one reason or another. GNU ld has got a list of libraries and
> object files to exclude, so any symbols from e.g. libmingwex or
> libmingw32 or dllcrt2.o won't get exported.
>
> However, libmsvcrt is missing from that list (and libucrtbase
> obviously isn't present either). In LLD, libmsvcrt and libucrtbase
> are part of the library exclude list.
>
> By linking with -Wl,--exclude-libs,libucrtbase.a, one can manually
> request to exclude any symbols from this library.
>
> There are a number of exceptions to the rules for autoexporting
> (which aren't clearly documented but can be found in ld/pe-dll.c
> in GNU binutils). One that seems to cover the cases that currently
> are found in libmsvcrt.a, explaining why such symbols haven't
> been exported before, is that a symbol foo won't be exported, if a
> corresponding symbol __imp_foo also is defined.
>
> We can use this to add __imp_ prefixed symbols for symbols that
> strictly don't need it (where no calling code currently refers to
> it with a dllimport attribute).
>
> Make the _CRTALLOC pointer static with an attribute indicating that
> it is used and should be kept even though unreferenced.
>
> All in all, this avoids exporting unintentional symbols from DLLs
> that link to ucrtbase, even though it might be desireable to
> add libmsvcrt and libucrtbase to the built-in exclude list as well.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/crt/ucrtbase_compat.c | 16 +++-
> mingw-w64-crt/stdio/ucrt__vsnprintf.c | 1 +
> mingw-w64-crt/stdio/ucrt_fprintf.c| 1 +
> mingw-w64-crt/stdio/ucrt_printf.c | 1 +
> mingw-w64-crt/stdio/ucrt_snprintf.c | 1 +
> mingw-w64-crt/stdio/ucrt_sprintf.c| 1 +
> mingw-w64-crt/stdio/ucrt_vfprintf.c | 1 +
> mingw-w64-crt/stdio/ucrt_vprintf.c| 1 +
> mingw-w64-crt/stdio/ucrt_vsnprintf.c | 1 +
> mingw-w64-crt/stdio/ucrt_vsprintf.c | 1 +
> 10 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c
> b/mingw-w64-crt/crt/ucrtbase_compat.c
> index 53e44f6..9d580df 100644
> --- a/mingw-w64-crt/crt/ucrtbase_compat.c
> +++ b/mingw-w64-crt/crt/ucrtbase_compat.c
> @@ -153,7 +153,7 @@ static void __cdecl init_compat_dtor(void)
>atexit(free_locks);
> }
>
> -_CRTALLOC(".CRT$XID") _PVFV mingw_ucrtbase_compat_init = init_compat_dtor;
> +static _CRTALLOC(".CRT$XID") __attribute__((__used__)) _PVFV
> mingw_ucrtbase_compat_init = init_compat_dtor;
>
>
> // These are required to provide the unrepfixed data symbols "timezone"
> @@ -226,6 +226,20 @@ int __cdecl __ms_fwprintf(FILE *file, const wchar_t
> *fmt, ...)
>va_end(ap);
>return ret;
> }
> +
> +// Dummy/unused __imp_ wrappers, to make GNU ld not autoexport these symbols.
> +int __cdecl (*__MINGW_IMP_SYMBOL(__getmainargs))(int *, char ***, char ***,
> int, _startupinfo *) = __getmainargs;
> +int __cdecl (*__MINGW_IMP_SYMBOL(__wgetmainargs))(int *, wchar_t ***,
> wchar_t ***, int, _startupinfo *) = __wgetmainargs;
> +_onexit_t __cdecl (*__MINGW_IMP_SYMBOL(__dllonexit))(_onexit_t, _PVFV**,
> _PVFV**) = __dllonexit;
> +void __cdecl (*__MINGW_IMP_SYMBOL(_amsg_exit))(int) = _amsg_exit;
> +unsigned int __cdecl (*__MINGW_IMP_SYMBOL(_get_output_format))(void) =
> _get_output_format;
> +void __cdecl (*__MINGW_IMP_SYMBOL(_tzset))(void) = _tzset;
> +void __cdecl (*__MINGW_IMP_SYMBOL(tzset))(void) = tzset;
> +void __cdecl (*__MINGW_IMP_SYMBOL(_lock))(int) = _lock;
> +void __cdecl (*__MINGW_IMP_SYMBOL(_unlock))(int) = _unlock;
> +int __cdecl (*__MINGW_IMP_SYMBOL(fwprintf))(FILE *, const wchar_t *, ...) =
> fwprintf;
> +int __cdecl (*__MINGW_IMP_SYMBOL(_snwprintf))(wchar_t *restrict, size_t,
> const wchar_t *restrict, ...) = _snwprintf;
> +int __cdecl (*__MINGW_IMP_SYMBOL(__ms_fwprintf))(FILE *, const wchar_t *,
> ...) = __ms_fwprintf;
> #ifdef __GNUC__
> #pragma GCC diagnostic pop
> #endif
> diff --git a/mingw-w64-crt/stdio/ucrt__vsnprintf.c
> b/mingw-w64-crt/stdio/ucrt__vsnprintf.c
> index 6828007..58f29f1 100644
> --- a/mingw-w64-crt/stdio/ucrt__vsnprintf.c
> +++ b/mingw-w64-crt/stdio/ucrt__vsnprintf.c
> @@ -12,3 +12,4 @@ int __cdecl _vsnprintf(char * __restrict__ _Dest,size_t
> _Count,const char * __re
> {
>return
> __stdio_common_vsprintf(UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION,
> _Dest, _Count, _Format, NULL, _Args);
> }
> +int __cdecl (*__MINGW_IMP_SYMBOL(_vsnprintf))(char *__restrict__, size_t,
> const char *__restrict__, va_list) = _vsnprintf;
> diff --git a/mi
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 thought it was >> one of the runtime dll entry points that one didn't really want to link toso >> that it wouldn't matter. But I can keep it just in case so it won't end up >> as a surprise. > > > Pushed with this function kept, thanks! > > // Martin Thank you :) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
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/shlwapi.def | 935
>
> mingw-w64-crt/libarm64/Makefile.am | 1 +
> 3 files changed, 13 insertions(+), 938 deletions(-)
> rename mingw-w64-crt/{lib64 => lib-common}/shlwapi.def (96%)
> delete mode 100644 mingw-w64-crt/libarm32/shlwapi.def
>
> diff --git a/mingw-w64-crt/lib64/shlwapi.def
> b/mingw-w64-crt/lib-common/shlwapi.def
> similarity index 96%
> rename from mingw-w64-crt/lib64/shlwapi.def
> rename to mingw-w64-crt/lib-common/shlwapi.def
> index 7f5e88e..f8ef132 100644
> --- a/mingw-w64-crt/lib64/shlwapi.def
> +++ b/mingw-w64-crt/lib-common/shlwapi.def
> @@ -1,7 +1,7 @@
> ;
> ; Definition file of SHLWAPI.dll
> ; Automatic generated by gendef
> -; written by Kai Tietz 2008
> +; written by Kai Tietz 2008-2014
> ;
> LIBRARY "SHLWAPI.dll"
> EXPORTS
> @@ -24,6 +24,8 @@ StrCmpCA
> StrCmpCW
> StrCmpICA
> StrCmpICW
> +IUnknown_QueryStatus
> +IUnknown_Exec
> ConnectToConnectionPoint
> IUnknown_AtomicRelease
> IUnknown_GetWindow
> @@ -40,11 +42,16 @@ IStream_Reset
> IStream_Size
> SHAnsiToUnicode
> SHUnicodeToAnsi
> +SHUnicodeToAnsiCP
> QISearch
> SHStripMneumonicW
> +SHPinDllOfCLSID
> IUnknown_GetSite
> +GUIDFromStringW
> WhichPlatform
> +SHCreateWorkerWindowW
> SHRegGetIntW
> +SHPackDispParamsV
> SHAnsiToAnsi
> SHUnicodeToUnicode
> SHFormatDateTimeA
> @@ -56,6 +63,7 @@ MLFreeLibrary
> SHSendMessageBroadcastA
> SHSendMessageBroadcastW
> IsOS
> +PathFileExistsAndAttributesW
> UrlFixupW
> SHRunIndirectRegClientCommand
> SHLoadIndirectString
> @@ -83,15 +91,16 @@ ColorHLSToRGB
> IStream_ReadStr
> IStream_WriteStr
> ColorRGBToHLS
> -DllGetVersion
> GetMenuPosFromID
> HashData
> -IntlStrEqWorkerA
> SHCreateThreadWithHandle
> +IntlStrEqWorkerA
> IntlStrEqWorkerW
> IsCharSpaceA
> PathAddBackslashA
> PathAddBackslashW
> +SHRegGetValueFromHKCUHKLM
> +SHRegGetBoolValueFromHKCUHKLM
> PathAddExtensionA
> PathAddExtensionW
> PathAppendA
> diff --git a/mingw-w64-crt/libarm32/shlwapi.def
> b/mingw-w64-crt/libarm32/shlwapi.def
> deleted file mode 100644
> index a2616f2..000
> diff --git a/mingw-w64-crt/libarm64/Makefile.am
> b/mingw-w64-crt/libarm64/Makefile.am
> index 51d2ba1..735192c 100644
> --- a/mingw-w64-crt/libarm64/Makefile.am
> +++ b/mingw-w64-crt/libarm64/Makefile.am
> @@ -228,6 +228,7 @@ libarm64_DATA += %reldir%/libserwvdrv.a
> #libarm64_DATA += %reldir%/libshell32.a# Handled by custom rule
> libarm64_DATA += %reldir%/libshfolder.a
> libarm64_DATA += %reldir%/libshimgvw.a
> +libarm64_DATA += %reldir%/libshlwapi.a
> libarm64_DATA += %reldir%/libshsvcs.a
> libarm64_DATA += %reldir%/libsisbkup.a
> libarm64_DATA += %reldir%/libslcext.a
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
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 __mingw_ovr is plain "inline __cdecl" > in C++, while it does include "static" in C). > > However, swprintf.inl and wchar.h redefine __mingw_ovr to also include > static even for C++, for GCC (and anything defining __GNUC__), leading > to a double "static static" in C++ mode, if these headers are included > last. > --- > mingw-w64-headers/crt/swprintf.inl | 4 > mingw-w64-headers/crt/wchar.h | 4 > 2 files changed, 8 insertions(+) > > diff --git a/mingw-w64-headers/crt/swprintf.inl > b/mingw-w64-headers/crt/swprintf.inl > index d7db2ad..f96be98 100644 > --- a/mingw-w64-headers/crt/swprintf.inl > +++ b/mingw-w64-headers/crt/swprintf.inl > @@ -12,6 +12,10 @@ > #undef __mingw_ovr > #if defined (__GNUC__) > #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl > +#ifdef __mingw_static_ovr > +#undef __mingw_static_ovr > +#define __mingw_static_ovr __mingw_ovr > +#endif > #elif defined(__cplusplus) > #define __mingw_ovr inline __cdecl > #else > diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h > index 61c0a41..6783a22 100644 > --- a/mingw-w64-headers/crt/wchar.h > +++ b/mingw-w64-headers/crt/wchar.h > @@ -507,6 +507,10 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[];/* A > pointer to an array of FILE */ > #undef __mingw_ovr > #if defined (__GNUC__) > #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl > +#ifdef __mingw_static_ovr > +#undef __mingw_static_ovr > +#define __mingw_static_ovr __mingw_ovr > +#endif > #elif defined(__cplusplus) > #define __mingw_ovr inline __cdecl > #else > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Revert "Avoid collisions for imported Interlocked symbols by VC generated code."
Hmm, I am not sure that this will actually fix just llvm, but break everything else. We provide the Interloced API as inline functions/builtins on gcc. So we don't want those symbols to be exported, as we want to use our own version instead. The reasoning is that such builtins might be optimizable. Just in case somebody wants to reference to them as 'function' pointer, we provide the imp.. variant. So could you please explain more detailed, what you intend to fix by this? Cheers, Kai 2017-11-13 16:51 GMT+01:00 Martin Storsjö : > This reverts commit bea244b471878eb6924463987eddb04cc581e306. > Unfortunately this would also reintroduce the issue that commit > fixed - but the commit doesn't elaborate on the details of those > issues. > > We need to provide the version of these functions without a __imp_ > prefix. Even though calling code normally will use the __imp_ prefixed > version (since it is declared with a dllimport attribute in the headers), > statically initialized data (e.g. a global pointer or table containing > pointers, initialized to point to InterlockedCompareExchange) will end > up referencing the unprefixed version. > > GNU ld can fix up that automatically during linking, but lld can't. > > This fixes linking sqlite3 (as part of Qt) with clang/lld for i686. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/lib32/kernel32.def | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/mingw-w64-crt/lib32/kernel32.def > b/mingw-w64-crt/lib32/kernel32.def > index 5b75f89..ece261f 100644 > --- a/mingw-w64-crt/lib32/kernel32.def > +++ b/mingw-w64-crt/lib32/kernel32.def > @@ -763,13 +763,13 @@ InitializeCriticalSectionEx@12 > InitializeProcThreadAttributeList@16 > InitializeSListHead@4 > InitializeSRWLock@4 > -InterlockedCompareExchange64@20 DATA ; FIXME: this is for Vista+. forwards > to NTDLL.RtlInterlockedCompareExchange64@20 > -InterlockedCompareExchange@12 DATA > -InterlockedDecrement@4 DATA > -InterlockedExchange@8 DATA > -InterlockedExchangeAdd@8 DATA > +InterlockedCompareExchange64@20 ; FIXME: this is for Vista+. forwards to > NTDLL.RtlInterlockedCompareExchange64@20 > +InterlockedCompareExchange@12 > +InterlockedDecrement@4 > +InterlockedExchange@8 > +InterlockedExchangeAdd@8 > InterlockedFlushSList@4 > -InterlockedIncrement@4 DATA > +InterlockedIncrement@4 > InterlockedPopEntrySList@4 > InterlockedPushEntrySList@8 > InvalidateConsoleDIBits@8 > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Provide __acrt_iob_func and __p___argv without the __imp_ prefix
Patch is Ok.
Thanks
Kai
2017-11-10 10:03 GMT+01:00 Martin Storsjö :
> 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
> easily provide the unprefixed version as well.
>
> This fixes linking with lld, which doesn't automatically resolve
> an undefined __acrt_iob_func reference to __imp___acrt_iob_func.
>
> Signed-off-by: Martin Storsjö
> ---
> This feels like a much better fix than the previous one.
> ---
> mingw-w64-crt/misc/__p___argv.c | 4 ++--
> mingw-w64-crt/stdio/acrt_iob_func.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mingw-w64-crt/misc/__p___argv.c b/mingw-w64-crt/misc/__p___argv.c
> index 06b348a..8e1f8ed 100644
> --- a/mingw-w64-crt/misc/__p___argv.c
> +++ b/mingw-w64-crt/misc/__p___argv.c
> @@ -6,10 +6,10 @@
>
> #include
>
> -static char ***__cdecl local__p___argv(void)
> +char ***__cdecl __p___argv(void)
> {
> return __MINGW_IMP_SYMBOL(__argv);
> }
>
> typedef char ***__cdecl (*_f__p___argv)(void);
> -_f__p___argv __MINGW_IMP_SYMBOL(__p___argv) = local__p___argv;
> +_f__p___argv __MINGW_IMP_SYMBOL(__p___argv) = __p___argv;
> diff --git a/mingw-w64-crt/stdio/acrt_iob_func.c
> b/mingw-w64-crt/stdio/acrt_iob_func.c
> index e8eb077..085a5fa 100644
> --- a/mingw-w64-crt/stdio/acrt_iob_func.c
> +++ b/mingw-w64-crt/stdio/acrt_iob_func.c
> @@ -6,10 +6,10 @@
>
> #include
>
> -static FILE *__cdecl local__acrt_iob_func(unsigned index)
> +FILE *__cdecl __acrt_iob_func(unsigned index)
> {
> return &(__iob_func()[index]);
> }
>
> typedef FILE *__cdecl (*_f__acrt_iob_func)(unsigned index);
> -_f__acrt_iob_func __MINGW_IMP_SYMBOL(__acrt_iob_func) = local__acrt_iob_func;
> +_f__acrt_iob_func __MINGW_IMP_SYMBOL(__acrt_iob_func) = __acrt_iob_func;
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] headers: Allow setting the default __MSVCRT_VERSION__
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 as parameter, which is mapped to a version, as suggested by Jacek. --- mingw-w64-crt/Makefile.am | 2 +- mingw-w64-crt/crt/ucrtbase_compat.c | 1 + mingw-w64-headers/configure.ac | 33 + mingw-w64-headers/crt/_mingw.h.in | 2 +- 4 files changed, 36 insertions(+), 2 deletions(-) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index a90c3ad..9d62c09 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -20,7 +20,7 @@ else endif AM_CPPFLAGS=$(sysincludes) -AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ +AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00 -D__MSVCRT_VERSION__=0x700 @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@ AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@ CPPFLAGSARM32=-mfpu=vfp CPPFLAGS32=-m32 diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c b/mingw-w64-crt/crt/ucrtbase_compat.c index f955e93..749fc62 100644 --- a/mingw-w64-crt/crt/ucrtbase_compat.c +++ b/mingw-w64-crt/crt/ucrtbase_compat.c @@ -9,6 +9,7 @@ #pragma GCC diagnostic ignored "-Winline" #endif +#undef __MSVCRT_VERSION__ #define __MSVCRT_VERSION__ 0x1400 #define vfprintf real_vfprintf diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index 21259d3..d83037e 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -162,6 +162,39 @@ AC_MSG_RESULT([$with_default_win32_winnt]) AS_VAR_SET([DEFAULT_WIN32_WINNT],[$with_default_win32_winnt]) AC_SUBST([DEFAULT_WIN32_WINNT]) +AC_MSG_CHECKING([default msvcrt]) +AC_ARG_WITH([default-msvcrt], + [AS_HELP_STRING([--with-default-msvcrt=LIB], +[Default msvcrt to target (default: msvcrt)])], + [], + [with_default_msvcrt=msvcrt]) +case $with_default_msvcrt in +msvcr80*) + default_msvcrt_version=0x800 + ;; +msvcr90*) + default_msvcrt_version=0x900 + ;; +msvcr100*) + default_msvcrt_version=0x1000 + ;; +msvcr110*) + default_msvcrt_version=0x1100 + ;; +msvcr120*) + default_msvcrt_version=0x1200 + ;; +ucrt*) + default_msvcrt_version=0x1400 + ;; +msvcrt|*) + default_msvcrt_version=0x700 + ;; +esac +AC_MSG_RESULT([$with_default_msvcrt ($default_msvcrt_version)]) +AS_VAR_SET([DEFAULT_MSVCRT_VERSION],[$default_msvcrt_version]) +AC_SUBST([DEFAULT_MSVCRT_VERSION]) + # Checks for typedefs, structures, and compiler characteristics. # Checks for library functions. diff --git a/mingw-w64-headers/crt/_mingw.h.in b/mingw-w64-headers/crt/_ mingw.h.in index c7b07ed..23fe7d7 100644 --- a/mingw-w64-headers/crt/_mingw.h.in +++ b/mingw-w64-headers/crt/_mingw.h.in @@ -217,7 +217,7 @@ limitations in handling dllimport attribute. */ #ifndef __MSVCRT_VERSION__ /* High byte is the major version, low byte is the minor. */ -# define __MSVCRT_VERSION__ 0x0700 +# define __MSVCRT_VERSION__ @DEFAULT_MSVCRT_VERSION@ #endif -- 2.7.4 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library
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 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. --- mingw-w64-crt/Makefile.am | 60 +- mingw-w64-crt/configure.ac | 14 + mingw-w64-crt/lib32/Makefile.am| 1 - mingw-w64-crt/lib64/Makefile.am| 1 - mingw-w64-crt/libarm32/Makefile.am | 1 - mingw-w64-crt/libarm64/Makefile.am | 1 - 6 files changed, 54 insertions(+), 24 deletions(-) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index 9d62c09..450ccd8 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -480,12 +480,17 @@ lib32_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs32) lib32_libkernel32_a_AR = $(DTLIB32) && $(AR) $(ARFLAGS) lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS) +lib32_DATA = if !W32API -lib32_LIBRARIES += lib32/libmsvcrt.a -lib32_libmsvcrt_a_SOURCES = $(src_msvcrt32) lib-common/msvcrt.def.in -lib32_libmsvcrt_a_AR = $(DTDEF32) lib32/msvcrt.def && $(AR) $(ARFLAGS) -lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) -EXTRA_lib32_libmsvcrt_a_DEPENDENCIES=lib32/msvcrt.def +lib32_DATA += lib32/libmsvcrt.a +lib32/libmsvcrt.a: lib32/@MSVCRT_LIB@ + cp $< $@ + +lib32_LIBRARIES += lib32/libmsvcrt-os.a +lib32_libmsvcrt_os_a_SOURCES = $(src_msvcrt32) lib-common/msvcrt.def.in +lib32_libmsvcrt_os_a_AR = $(DTDEF32) lib32/msvcrt.def && $(AR) $(ARFLAGS) +lib32_libmsvcrt_os_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) +EXTRA_lib32_libmsvcrt_os_a_DEPENDENCIES=lib32/msvcrt.def endif lib32_LIBRARIES += lib32/libshell32.a @@ -832,12 +837,17 @@ lib64_libkernel32_a_CPPFLAGS=$(CPPFLAGS64) $(extra_include) $(AM_CPPFLAGS) lib64_libkernel32_a_AR = $(DTDEF64) lib64/kernel32.def && $(AR) $(ARFLAGS) EXTRA_lib64_libkernel32_a_DEPENDENCIES=lib64/kernel32.def +lib64_DATA = if !W32API -lib64_LIBRARIES += lib64/libmsvcrt.a -lib64_libmsvcrt_a_SOURCES = $(src_msvcrt64) lib-common/msvcrt.def.in -lib64_libmsvcrt_a_AR = $(DTDEF64) lib64/msvcrt.def && $(AR) $(ARFLAGS) -lib64_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS64) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) -EXTRA_lib64_libmsvcrt_a_DEPENDENCIES=lib64/msvcrt.def +lib64_DATA += lib64/libmsvcrt.a +lib64/libmsvcrt.a: lib64/@MSVCRT_LIB@ + cp $< $@ + +lib64_LIBRARIES += lib64/libmsvcrt-os.a +lib64_libmsvcrt_os_a_SOURCES = $(src_msvcrt64) lib-common/msvcrt.def.in +lib64_libmsvcrt_os_a_AR = $(DTDEF64) lib64/msvcrt.def && $(AR) $(ARFLAGS) +lib64_libmsvcrt_os_a_CPPFLAGS=$(CPPFLAGS64) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) +EXTRA_lib64_libmsvcrt_os_a_DEPENDENCIES=lib64/msvcrt.def endif lib64_LIBRARIES += lib64/libshell32.a @@ -1199,12 +1209,17 @@ libarm32_libkernel32_a_AR = $(DTDEFARM32) libarm32/kernel32.def && $(AR) $(ARFLA libarm32_libkernel32_a_CPPFLAGS=$(CPPFLAGSARM32) $(extra_include) $(AM_CPPFLAGS) EXTRA_libarm32_libkernel32_a_DEPENDENCIES=libarm32/kernel32.def +libarm32_DATA = if !W32API -libarm32_LIBRARIES += libarm32/libmsvcrt.a -libarm32_libmsvcrt_a_SOURCES = $(src_msvcrtarm32) lib-common/msvcrt.def.in -libarm32_libmsvcrt_a_AR = $(DTDEFARM32) libarm32/msvcrt.def && $(AR) $(ARFLAGS) -libarm32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGSARM32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) -EXTRA_libarm32_libmsvcrt_a_DEPENDENCIES=libarm32/msvcrt.def +libarm32_DATA += libarm32/libmsvcrt.a +libarm32/libmsvcrt.a: libarm32/@MSVCRT_LIB@ + cp $< $@ + +libarm32_LIBRARIES += libarm32/libmsvcrt-os.a +libarm32_libmsvcrt_os_a_SOURCES = $(src_msvcrtarm32) lib-common/ msvcrt.def.in +libarm32_libmsvcrt_os_a_AR = $(DTDEFARM32) libarm32/msvcrt.def && $(AR) $(ARFLAGS) +libarm32_libmsvcrt_os_a_CPPFLAGS=$(CPPFLAGSARM32) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) +EXTRA_libarm32_libmsvcrt_os_a_DEPENDENCIES=libarm32/msvcrt.def endif libarm32_LIBRARIES += libarm32/libshell32.a @@ -1456,12 +1471,17 @@ libarm64_libkernel32_a_AR = $(DTDEFARM64) libarm64/kernel32.def && $(AR) $(ARFLA libarm64_libkernel32_a_CPPFLAGS=$(CPPFLAGSARM64) $(extra_include) $(AM_CPPFLAGS) EXTRA_libarm64_libkernel32_a_DEPENDENCIES=libarm64/kernel32.def +libarm64_DATA = if !W32API -libarm64_LIBRARIES += libarm64/libmsvcrt.a -libarm64_libmsvcrt_a_SOURCES = $(src_msvcrtarm64) lib-common/msvcrt.def.in -libarm64_libmsvcrt_a_AR = $(DTDEFARM64) libarm64/msvcrt.def && $(AR) $(ARFLAGS) -libarm64_libmsvcrt_a_CPPFLAGS=$(CPPFLAGSARM64) -D__LIBMSVCRT__ $(extra_include) $(sysincludes) -EXTRA_libarm64_libmsvcrt_a_DEPENDENCIES=libarm64/msvcrt.def +libarm64_DATA += libarm64/libmsvcrt.a +libarm64/libmsvcrt.a: libarm6
Re: [Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library
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. 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. > > > Ok, so what name do you suggest we give the file that currently is called > libmsvcrt.a if we enable this configure option? > > // Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] crt: Allow overriding libmsvcrt.a to point to another library
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 GMT+01:00 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
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -477,11 +477,16 @@ lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32)
> $(extra_include) $(AM_CPPFLAGS)
>
> if !W32API
> lib32_LIBRARIES += lib32/libmsvcrt.a
> +if OVERRIDE_MSVCRT
> +lib32_libmsvcrt_a_AR = cp lib32/@MSVCRT_LIB@
> +EXTRA_lib32_libmsvcrt_a_DEPENDENCIES=lib32/@MSVCRT_LIB@
> +else
> lib32_libmsvcrt_a_SOURCES = $(src_msvcrt32) lib-common/msvcrt.def.in
> lib32_libmsvcrt_a_AR = $(DTDEF32) lib32/msvcrt.def && $(AR) $(ARFLAGS)
> lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include)
> $(sysincludes)
> EXTRA_lib32_libmsvcrt_a_DEPENDENCIES=lib32/msvcrt.def
> endif
> +endif
>
> lib32_LIBRARIES += lib32/libshell32.a
> lib32_libshell32_a_SOURCES = $(src_libshell32)
> @@ -779,11 +784,16 @@
> EXTRA_lib64_libkernel32_a_DEPENDENCIES=lib64/kernel32.def
>
> if !W32API
> lib64_LIBRARIES += lib64/libmsvcrt.a
> +if OVERRIDE_MSVCRT
> +lib64_libmsvcrt_a_AR = cp lib64/@MSVCRT_LIB@
> +EXTRA_lib64_libmsvcrt_a_DEPENDENCIES=lib64/@MSVCRT_LIB@
> +else
> lib64_libmsvcrt_a_SOURCES = $(src_msvcrt64) lib-common/msvcrt.def.in
> lib64_libmsvcrt_a_AR = $(DTDEF64) lib64/msvcrt.def && $(AR) $(ARFLAGS)
> lib64_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS64) -D__LIBMSVCRT__ $(extra_include)
> $(sysincludes)
> EXTRA_lib64_libmsvcrt_a_DEPENDENCIES=lib64/msvcrt.def
> endif
> +endif
>
> lib64_LIBRARIES += lib64/libshell32.a
> lib64_libshell32_a_SOURCES = $(src_libshell32)
> @@ -1102,11 +1112,16 @@
> EXTRA_libarm32_libkernel32_a_DEPENDENCIES=libarm32/kernel32.def
>
> if !W32API
> libarm32_LIBRARIES += libarm32/libmsvcrt.a
> +if OVERRIDE_MSVCRT
> +libarm32_libmsvcrt_a_AR = cp libarm32/@MSVCRT_LIB@
> +EXTRA_libarm32_libmsvcrt_a_DEPENDENCIES=libarm32/@MSVCRT_LIB@
> +else
> libarm32_libmsvcrt_a_SOURCES = $(src_msvcrtarm32) lib-common/msvcrt.def.in
> libarm32_libmsvcrt_a_AR = $(DTDEFARM32) libarm32/msvcrt.def && $(AR)
> $(ARFLAGS)
> libarm32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGSARM32) -D__LIBMSVCRT__
> $(extra_include) $(sysincludes)
> EXTRA_libarm32_libmsvcrt_a_DEPENDENCIES=libarm32/msvcrt.def
> endif
> +endif
>
> libarm32_LIBRARIES += libarm32/libshell32.a
> libarm32_libshell32_a_SOURCES = $(src_libshell32)
> @@ -1355,11 +1370,16 @@
> EXTRA_libarm64_libkernel32_a_DEPENDENCIES=libarm64/kernel32.def
>
> if !W32API
> libarm64_LIBRARIES += libarm64/libmsvcrt.a
> +if OVERRIDE_MSVCRT
> +libarm64_libmsvcrt_a_AR = cp libarm64/@MSVCRT_LIB@
> +EXTRA_libarm64_libmsvcrt_a_DEPENDENCIES=libarm64/@MSVCRT_LIB@
> +else
> libarm64_libmsvcrt_a_SOURCES = $(src_msvcrtarm64) lib-common/msvcrt.def.in
> libarm64_libmsvcrt_a_AR = $(DTDEFARM64) libarm64/msvcrt.def && $(AR)
> $(ARFLAGS)
> libarm64_libmsvcrt_a_CPPFLAGS=$(CPPFLAGSARM64) -D__LIBMSVCRT__
> $(extra_include) $(sysincludes)
> EXTRA_libarm64_libmsvcrt_a_DEPENDENCIES=libarm64/msvcrt.def
> endif
> +endif
>
> libarm64_LIBRARIES += libarm64/libshell32.a
> libarm64_libshell32_a_SOURCES = $(src_libshell32)
> diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
> index 8b8dd84..c234a2e 100644
> --- a/mingw-w64-crt/configure.ac
> +++ b/mingw-w64-crt/configure.ac
> @@ -233,6 +233,17 @@ AS_CASE([$enable_delay_import_libs],
> AM_CONDITIONAL([DELAY_IMPORT_LIBS],[test $enable_delay_import_libs = yes])
> AC_MSG_RESULT([$enable_delay_import_libs])
>
> +AC_MSG_CHECKING([what to provide as libmsvcrt.a])
> +AC_ARG_WITH([msvcrt],
> + [AS_HELP_STRING([--with-msvcrt=LIB],
> +[Lib to provide as libmsvcrt.a (default: msvcrt)])],
> + [],
> + [with_msvcrt=msvcrt])
> +AC_MSG_RESULT([$with_msvcrt])
> +AM_CONDITIONAL([OVERRIDE_MSVCRT],[ test "$with_msvcrt" != "msvcrt" ])
> +AS_VAR_SET([MSVCRT_LIB],[lib${with_msvcrt}.a])
> +AC_SUBST([MSVCRT_LIB])
> +
> AC_MSG_CHECKING([whether to enable experimental features])
> AC_ARG_ENABLE([experimental],
>[AS_HELP_STRING([--enable-experimental],
> @@ -368,6 +379,7 @@ AC_MSG_NOTICE([ Win64 runtime: $enable_lib64])
> AC_MSG_NOTICE([ C Warning Flags..: $ADD_C_ONLY_WARNING_FLAGS])
> AC_MSG_NOTICE([ C++ Warning Flags: $ADD_CXX_ONLY_WARNING_FLAGS])
> AC_MSG_NOTICE([ Common Warning Flags.: $ADD_C_CXX_WARNING_FLAGS])
> +AC_MSG_NOTICE([ Default msvcrt...: $with_msvcrt])
> AC_MSG_NOTICE([])
> AC_MSG_NOTICE([ DFP printf...: $enable_dfp])
> AC_MSG_NOTICE([ 128-bit printf...: $enable_printf128])
> --
> 2.7.4
>
>
>
Re: [Mingw-w64-public] [PATCHv2 3/3] crt: Provide __p___argv in all msvcrt versions
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 makes sure that code in libmingwex (getopt.c) that references
> __argv will work regardless of which msvcrt/ucrtbase it ends up
> linked to.
>
> Signed-off-by: Martin Storsjö
> ---
> Updated the implementation of __p___argv to refer to
> __MINGW_IMP_SYMBOL(__argv) instead of __argv, since the latter
> now refers back to __p___argv and recurses infinitely. Made the
> function static and with a different name, to avoid warnings about
> inconsistent dllimport attributes.
> ---
> mingw-w64-crt/Makefile.am | 29 +
> mingw-w64-crt/misc/__p___argv.c | 15 +++
> mingw-w64-headers/crt/stdlib.h | 6 --
> 3 files changed, 44 insertions(+), 6 deletions(-)
> create mode 100644 mingw-w64-crt/misc/__p___argv.c
>
> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
> index 2ce1f83..3683521 100644
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -211,6 +211,21 @@ src_msvcrt32=\
>$(src_msvcrt) \
>misc/lc_locale_func.c
>
> +src_msvcrt64=\
> + $(src_msvcrt) \
> + misc/__p___argv.c
> +
> +src_msvcrtarm32=\
> + $(src_msvcrt) \
> + misc/__p___argv.c
> +
> +src_msvcrtarm64=\
> + $(src_msvcrt) \
> + misc/__p___argv.c
> +
> +src_msvcr80_64=\
> + misc/__p___argv.c
> +
> # These mingwex sources are target independent:
> src_libmingwex=\
>crt/dllentry.ccrt/dllmain.c \
> @@ -764,7 +779,7 @@ EXTRA_lib64_libkernel32_a_DEPENDENCIES=lib64/kernel32.def
>
> if !W32API
> lib64_LIBRARIES += lib64/libmsvcrt.a
> -lib64_libmsvcrt_a_SOURCES = $(src_msvcrt) lib-common/msvcrt.def.in
> +lib64_libmsvcrt_a_SOURCES = $(src_msvcrt64) lib-common/msvcrt.def.in
> lib64_libmsvcrt_a_AR = $(DTDEF64) lib64/msvcrt.def && $(AR) $(ARFLAGS)
> lib64_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS64) -D__LIBMSVCRT__ $(extra_include)
> $(sysincludes)
> EXTRA_lib64_libmsvcrt_a_DEPENDENCIES=lib64/msvcrt.def
> @@ -926,10 +941,16 @@ endif
> include lib64/Makefile.am
>
> if !W32API
> -lib64_DATA += lib64/libmsvcp60.a lib64/libmsvcr80.a lib64/libmsvcr90.a
> lib64/libmsvcr100.a lib64/libmsvcr90d.a \
> +lib64_DATA += lib64/libmsvcp60.a lib64/libmsvcr90.a lib64/libmsvcr100.a
> lib64/libmsvcr90d.a \
> lib64/libmsvcr110.a lib64/libmsvcr120.a
> lib64/libmsvcr120d.a lib64/libcrtdll.a \
> lib64/libmsvcr120_app.a lib64/libmsvcp120_app.a
>
> +lib64_LIBRARIES += lib64/libmsvcr80.a
> +lib64_libmsvcr80_a_SOURCES = $(src_msvcr80_64) lib64/msvcr80.def.in
> +lib64_libmsvcr80_a_AR = $(DTDEF64) lib64/msvcr80.def && $(AR) $(ARFLAGS)
> +lib64_libmsvcr80_a_CPPFLAGS=$(CPPFLAGS64) -D__LIBMSVCRT__ $(extra_include)
> $(sysincludes)
> +EXTRA_lib64_libmsvcr80_a_DEPENDENCIES=lib64/msvcr80.def
> +
> lib64_LIBRARIES += lib64/libucrtbase.a
> lib64_libucrtbase_a_SOURCES = $(src_ucrtbase) lib-common/ucrtbase.def.in
> lib64_libucrtbase_a_AR = $(DTDEF64) lib64/ucrtbase.def && $(AR) $(ARFLAGS)
> @@ -1081,7 +1102,7 @@
> EXTRA_libarm32_libkernel32_a_DEPENDENCIES=libarm32/kernel32.def
>
> if !W32API
> libarm32_LIBRARIES += libarm32/libmsvcrt.a
> -libarm32_libmsvcrt_a_SOURCES = $(src_msvcrt) lib-common/msvcrt.def.in
> +libarm32_libmsvcrt_a_SOURCES = $(src_msvcrtarm32) lib-common/msvcrt.def.in
> libarm32_libmsvcrt_a_AR = $(DTDEFARM32) libarm32/msvcrt.def && $(AR)
> $(ARFLAGS)
> libarm32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGSARM32) -D__LIBMSVCRT__
> $(extra_include) $(sysincludes)
> EXTRA_libarm32_libmsvcrt_a_DEPENDENCIES=libarm32/msvcrt.def
> @@ -1334,7 +1355,7 @@
> EXTRA_libarm64_libkernel32_a_DEPENDENCIES=libarm64/kernel32.def
>
> if !W32API
> libarm64_LIBRARIES += libarm64/libmsvcrt.a
> -libarm64_libmsvcrt_a_SOURCES = $(src_msvcrt) lib-common/msvcrt.def.in
> +libarm64_libmsvcrt_a_SOURCES = $(src_msvcrtarm64) lib-common/msvcrt.def.in
> libarm64_libmsvcrt_a_AR = $(DTDEFARM64) libarm64/msvcrt.def && $(AR)
> $(ARFLAGS)
> libarm64_libmsvcrt_a_CPPFLAGS=$(CPPFLAGSARM64) -D__LIBMSVCRT__
> $(extra_include) $(sysincludes)
> EXTRA_libarm64_libmsvcrt_a_DEPENDENCIES=libarm64/msvcrt.def
> diff --git a/mingw-w64-crt/misc/__p___argv.c b/mingw-w64-crt/misc/__p___argv.c
> new file mode 100644
> index 000..06b348a
> --- /dev/null
> +++ b/mingw-w64-crt/misc/__p___argv.c
> @@ -0,0 +1,15 @@
> +/**
> + * This file has no copyright assigned and is placed in the Public Domain.
> + * This file is part of the mingw-w64 runtime package.
> + * No warranty is given; refer to the file DISCLAIMER.PD within this package.
> + */
> +
> +#include
> +
> +static char ***__cdecl local__p___argv(void)
> +{
> +return __MINGW_IMP_SYMBOL(__argv);
> +}
> +
> +typedef char ***__cdecl (*_f__p___argv)(void);
> +_f__p___argv __MINGW_IMP_SYMBOL(__p___argv) = local__p___argv;
> diff --git a/ming
Re: [Mingw-w64-public] [PATCH] headers: Default to the legacy wide string mode for ucrtbase, unless __USE_MINGW_ANSI_STDIO is defined
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 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ö > --- > mingw-w64-headers/crt/stdio.h | 7 --- > mingw-w64-headers/crt/wchar.h | 7 --- > 2 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h > index fcad9e2..c702d5f 100644 > --- a/mingw-w64-headers/crt/stdio.h > +++ b/mingw-w64-headers/crt/stdio.h > @@ -158,12 +158,13 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[]; /* A > pointer to an array of FILE */ > #define UCRTBASE_SCANF_LEGACY_WIDE_SPECIFIERS(0x0002) > #define UCRTBASE_SCANF_LEGACY_MSVCRT_COMPATIBILITY (0x0004) > > -// Default wide printfs and scanfs to the standard mode > +// Default wide printfs and scanfs to the legacy wide mode. Only code built > +// with -D__USE_MINGW_ANSI_STDIO=1 will expect the standard behaviour. > #ifndef UCRTBASE_PRINTF_DEFAULT_WIDE > -#define UCRTBASE_PRINTF_DEFAULT_WIDE 0 > +#define UCRTBASE_PRINTF_DEFAULT_WIDE UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS > #endif > #ifndef UCRTBASE_SCANF_DEFAULT_WIDE > -#define UCRTBASE_SCANF_DEFAULT_WIDE 0 > +#define UCRTBASE_SCANF_DEFAULT_WIDE UCRTBASE_SCANF_LEGACY_WIDE_SPECIFIERS > #endif > #endif > > diff --git a/mingw-w64-headers/crt/wchar.h b/mingw-w64-headers/crt/wchar.h > index a5bfbb8..926a0c4 100644 > --- a/mingw-w64-headers/crt/wchar.h > +++ b/mingw-w64-headers/crt/wchar.h > @@ -256,12 +256,13 @@ extern FILE (* __MINGW_IMP_SYMBOL(_iob))[]; /* A > pointer to an array of FILE */ > #define UCRTBASE_SCANF_LEGACY_WIDE_SPECIFIERS(0x0002) > #define UCRTBASE_SCANF_LEGACY_MSVCRT_COMPATIBILITY (0x0004) > > -// Default wide printfs and scanfs to the standard mode > +// Default wide printfs and scanfs to the legacy wide mode. Only code built > +// with -D__USE_MINGW_ANSI_STDIO=1 will expect the standard behaviour. > #ifndef UCRTBASE_PRINTF_DEFAULT_WIDE > -#define UCRTBASE_PRINTF_DEFAULT_WIDE 0 > +#define UCRTBASE_PRINTF_DEFAULT_WIDE UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS > #endif > #ifndef UCRTBASE_SCANF_DEFAULT_WIDE > -#define UCRTBASE_SCANF_DEFAULT_WIDE 0 > +#define UCRTBASE_SCANF_DEFAULT_WIDE UCRTBASE_SCANF_LEGACY_WIDE_SPECIFIERS > #endif > #endif > > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Don't include the new *_dbg functions on x86
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 preprocess into the exact same > list of functions as prior to unification on both 32 and 64 bit x86. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/lib-common/msvcrt.def.in | 36 > +- > 1 file changed, 18 insertions(+), 18 deletions(-) > > diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in > b/mingw-w64-crt/lib-common/msvcrt.def.in > index 9c1350e..6a7d6ad 100644 > --- a/mingw-w64-crt/lib-common/msvcrt.def.in > +++ b/mingw-w64-crt/lib-common/msvcrt.def.in > @@ -366,15 +366,15 @@ _adjust_fdiv DATA > #endif > _aexit_rtn DATA > _aligned_free > -_aligned_free_dbg > +F_ARM_ANY(_aligned_free_dbg) > _aligned_malloc > -_aligned_malloc_dbg > +F_ARM_ANY(_aligned_malloc_dbg) > _aligned_offset_malloc > -_aligned_offset_malloc_dbg > +F_ARM_ANY(_aligned_offset_malloc_dbg) > _aligned_offset_realloc > -_aligned_offset_realloc_dbg > +F_ARM_ANY(_aligned_offset_realloc_dbg) > _aligned_realloc > -_aligned_realloc_dbg > +F_ARM_ANY(_aligned_realloc_dbg) > _amsg_exit > _assert DATA > _atodbl > @@ -393,7 +393,7 @@ _beginthreadex > _c_exit > _cabs DATA > _callnewh > -_calloc_dbg > +F_ARM_ANY(_calloc_dbg) > _cexit > _cgets > ; _cgets_s replaced by emu > @@ -478,7 +478,7 @@ _execvp > _execvpe > _exit > _expand > -_expand_dbg > +F_ARM_ANY(_expand_dbg) > _fcloseall > _fcvt > _fcvt_s > @@ -519,7 +519,7 @@ _fprintf_p_l > _fprintf_s_l > _fputchar > _fputwchar > -_free_dbg > +F_ARM_ANY(_free_dbg) > _free_locale > F_ARM_ANY(_freea) > F_NON_I386(_fscanf_l) > @@ -540,7 +540,7 @@ F_I386(_ftime_s == _ftime32_s) > F_X64(_ftime_s == _ftime64_s) > F_I386(_ftol) > _fullpath > -_fullpath_dbg > +F_ARM_ANY(_fullpath_dbg) > _futime > F_ARM_ANY(_futime32) > _futime64 > @@ -723,7 +723,7 @@ _ltow > F_NON_I386(_ltow_s) > _makepath > _makepath_s > -_malloc_dbg > +F_ARM_ANY(_malloc_dbg) > _mbbtombc > _mbbtombc_l > _mbbtype > @@ -877,7 +877,7 @@ F_I386(_mktime32 == mktime) > F_ARM_ANY(_mktime32) > _mktime64 > _msize > -_msize_dbg > +F_ARM_ANY(_msize_dbg) > _nextafter > F_X64(_nextafterf) > _onexit F_I386(DATA) > @@ -906,7 +906,7 @@ _putwch > _putws > _pwctype DATA > _read > -_realloc_dbg > +F_ARM_ANY(_realloc_dbg) > _resetstkoflw > _rmdir > _rmtmp > @@ -1001,7 +1001,7 @@ _strcoll_l > _strdate > ; _strdate_s replaced by emu > _strdup > -_strdup_dbg > +F_ARM_ANY(_strdup_dbg) > _strerror > _strerror_s > _stricmp > @@ -1050,7 +1050,7 @@ _sys_nerr DATA > _tell > _telli64 > _tempnam > -_tempnam_dbg > +F_ARM_ANY(_tempnam_dbg) > F_I386(_time32 == time) > F_ARM_ANY(_time32) > _time64 > @@ -1145,7 +1145,7 @@ _wcmdln DATA > _wcreat > _wcscoll_l > _wcsdup > -_wcsdup_dbg > +F_ARM_ANY(_wcsdup_dbg) > _wcserror > _wcserror_s > _wcsftime_l > @@ -1219,7 +1219,7 @@ _wfreopen > _wfreopen_s > _wfsopen > _wfullpath > -_wfullpath_dbg > +F_ARM_ANY(_wfullpath_dbg) > _wgetcwd > _wgetdcwd > _wgetenv > @@ -1276,7 +1276,7 @@ _wstrtime > ; _wstrtime_s replaced by emu > _wsystem > _wtempnam > -_wtempnam_dbg > +F_ARM_ANY(_wtempnam_dbg) > _wtmpnam > _wtmpnam_s > _wtof > @@ -1417,7 +1417,7 @@ malloc > mblen > F_ARM_ANY(mbrlen) > F_ARM_ANY(mbrtowc) > -mbsdup_dbg > +F_ARM_ANY(mbsdup_dbg) > F_ARM_ANY(mbsrtowcs) > mbsrtowcs_s > mbstowcs > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/3] headers: Hook up __argc and similar external variables for ucrtbase
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 approved previously by JonY, but is rebased on top of an > updated patch. > --- > mingw-w64-headers/crt/stdlib.h | 48 > +++--- > 1 file changed, 45 insertions(+), 3 deletions(-) > > diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h > index 4e801ab..e46ea8c 100644 > --- a/mingw-w64-headers/crt/stdlib.h > +++ b/mingw-w64-headers/crt/stdlib.h > @@ -161,10 +161,18 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); >extern char *_sys_errlist[]; >extern int _sys_nerr; > #else > +#if __MSVCRT_VERSION__ >= 0x1400 > + _CRTIMP char **__cdecl __sys_errlist(void); > + _CRTIMP int *__cdecl __sys_nerr(void); > +#define _sys_nerr (*__sys_nerr()) > +#define _sys_errlist __sys_errlist(); > +#else >extern __declspec(dllimport) char *_sys_errlist[1]; >extern __declspec(dllimport) int _sys_nerr; > +#endif /* __MSVCRT_VERSION__ < 0x1400 */ > #endif > -#if (defined(_X86_) && !defined(__x86_64)) > + > +#if (defined(_X86_) && !defined(__x86_64)) || (__MSVCRT_VERSION__ >= 0x1400) >_CRTIMP int *__cdecl __p___argc(void); >_CRTIMP char ***__cdecl __p___argv(void); >_CRTIMP wchar_t ***__cdecl __p___wargv(void); > @@ -172,6 +180,7 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); >_CRTIMP wchar_t ***__cdecl __p__wenviron(void); >_CRTIMP char **__cdecl __p__pgmptr(void); >_CRTIMP wchar_t **__cdecl __p__wpgmptr(void); > + _CRTIMP int *__cdecl __p__fmode(void); > #endif > >errno_t __cdecl _get_pgmptr(char **_Value); > @@ -231,7 +240,40 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); >extern unsigned int _winminor; > #endif > > -#else /* _MSVCRT_ */ > +#elif __MSVCRT_VERSION__ >= 0x1400 > + > +#ifndef __argc > +#define __argc (* __p___argc()) > +#endif > +#ifndef __argv > +#define __argv (* __p___argv()) > +#endif > +#ifndef __wargv > +#define __wargv (* __p___wargv()) > +#endif > + > +#ifndef _POSIX_ > +#ifndef _environ > +#define _environ (* __p__environ()) > +#endif > + > +#ifndef _wenviron > +#define _wenviron (* __p__wenviron()) > +#endif > +#endif /* !_POSIX_ */ > + > +#ifndef _pgmptr > +#define _pgmptr (* __p__pgmptr()) > +#endif > + > +#ifndef _wpgmptr > +#define _wpgmptr (* __p__wpgmptr()) > +#endif > +#ifndef _fmode > +#define _fmode (* __p__fmode()) > +#endif > + > +#else /* __MSVCRT_VERSION__ >= 0x1400 */ > > #ifndef __argc >extern int * __MINGW_IMP_SYMBOL(__argc); > @@ -297,7 +339,7 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); > #define _winminor (* __MINGW_IMP_SYMBOL(_winminor)) > #endif > > -#endif /* !_MSVCRT_ */ > +#endif /* !_MSVCRT_ && __MSVCRT_VERSION__ < 0x1400 */ > >errno_t __cdecl _get_osplatform(unsigned int *_Value); >errno_t __cdecl _get_osver(unsigned int *_Value); > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/3] headers: Restructure declarations of external variables like __argc
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, but it's > a prerequisite for the patch that adds the ucrtbase versions of them. > --- > mingw-w64-headers/crt/stdlib.h | 117 > ++--- > 1 file changed, 62 insertions(+), 55 deletions(-) > > diff --git a/mingw-w64-headers/crt/stdlib.h b/mingw-w64-headers/crt/stdlib.h > index 7a1555a..4e801ab 100644 > --- a/mingw-w64-headers/crt/stdlib.h > +++ b/mingw-w64-headers/crt/stdlib.h > @@ -173,124 +173,131 @@ _CRTIMP int __cdecl ___mb_cur_max_func(void); >_CRTIMP char **__cdecl __p__pgmptr(void); >_CRTIMP wchar_t **__cdecl __p__wpgmptr(void); > #endif > -#ifndef __argc > + > + errno_t __cdecl _get_pgmptr(char **_Value); > + errno_t __cdecl _get_wpgmptr(wchar_t **_Value); > + _CRTIMP errno_t __cdecl _set_fmode(int _Mode); > + _CRTIMP errno_t __cdecl _get_fmode(int *_PMode); > + > #ifdef _MSVCRT_ > + > +#ifndef __argc >extern int __argc; > -#else > +#endif > +#ifndef __argv > + extern char **__argv; > +#endif > +#ifndef __wargv > + extern wchar_t **__wargv; > +#endif > + > +#ifndef _POSIX_ > +#ifndef _environ > + extern char **_environ; > +#endif > +#ifndef _wenviron > + extern wchar_t **_wenviron; > +#endif > +#endif /* !_POSIX_ */ > + > +#ifndef _pgmptr > + extern char *_pgmptr; > +#endif > + > +#ifndef _wpgmptr > + extern wchar_t *_wpgmptr; > +#endif > +#ifndef _fmode > + extern int _fmode; > +#endif > + > +#ifndef _osplatform > + extern unsigned int _osplatform; > +#endif > + > +#ifndef _osver > + extern unsigned int _osver; > +#endif > + > +#ifndef _winver > + extern unsigned int _winver; > +#endif > + > +#ifndef _winmajor > + extern unsigned int _winmajor; > +#endif > + > +#ifndef _winminor > + extern unsigned int _winminor; > +#endif > + > +#else /* _MSVCRT_ */ > + > +#ifndef __argc >extern int * __MINGW_IMP_SYMBOL(__argc); > #define __argc (* __MINGW_IMP_SYMBOL(__argc)) > #endif > -#endif > #ifndef __argv > -#ifdef _MSVCRT_ > - extern char **__argv; > -#else >extern char *** __MINGW_IMP_SYMBOL(__argv); > #define __argv (* __MINGW_IMP_SYMBOL(__argv)) > #endif > -#endif > #ifndef __wargv > -#ifdef _MSVCRT_ > - extern wchar_t **__wargv; > -#else >extern wchar_t *** __MINGW_IMP_SYMBOL(__wargv); > #define __wargv (* __MINGW_IMP_SYMBOL(__wargv)) > #endif > -#endif > > #ifndef _POSIX_ > #ifndef _environ > -#ifdef _MSVCRT_ > - extern char **_environ; > -#else >extern char *** __MINGW_IMP_SYMBOL(_environ); > #define _environ (* __MINGW_IMP_SYMBOL(_environ)) > #endif > -#endif > > #ifndef _wenviron > -#ifdef _MSVCRT_ > - extern wchar_t **_wenviron; > -#else >extern wchar_t *** __MINGW_IMP_SYMBOL(_wenviron); > #define _wenviron (* __MINGW_IMP_SYMBOL(_wenviron)) > #endif > -#endif > #endif /* !_POSIX_ */ > + > #ifndef _pgmptr > -#ifdef _MSVCRT_ > - extern char *_pgmptr; > -#else >extern char ** __MINGW_IMP_SYMBOL(_pgmptr); > #define _pgmptr(* __MINGW_IMP_SYMBOL(_pgmptr)) > #endif > -#endif > > #ifndef _wpgmptr > -#ifdef _MSVCRT_ > - extern wchar_t *_wpgmptr; > -#else >extern wchar_t ** __MINGW_IMP_SYMBOL(_wpgmptr); > #define _wpgmptr (* __MINGW_IMP_SYMBOL(_wpgmptr)) > #endif > -#endif > - errno_t __cdecl _get_pgmptr(char **_Value); > - errno_t __cdecl _get_wpgmptr(wchar_t **_Value); > #ifndef _fmode > -#ifdef _MSVCRT_ > - extern int _fmode; > -#else >extern int * __MINGW_IMP_SYMBOL(_fmode); > #define _fmode (* __MINGW_IMP_SYMBOL(_fmode)) > #endif > -#endif > - _CRTIMP errno_t __cdecl _set_fmode(int _Mode); > - _CRTIMP errno_t __cdecl _get_fmode(int *_PMode); > > #ifndef _osplatform > -#ifdef _MSVCRT_ > - extern unsigned int _osplatform; > -#else >extern unsigned int * __MINGW_IMP_SYMBOL(_osplatform); > #define _osplatform (* __MINGW_IMP_SYMBOL(_osplatform)) > #endif > -#endif > > #ifndef _osver > -#ifdef _MSVCRT_ > - extern unsigned int _osver; > -#else >extern unsigned int * __MINGW_IMP_SYMBOL(_osver); > #define _osver (* __MINGW_IMP_SYMBOL(_osver)) > #endif > -#endif > > #ifndef _winver > -#ifdef _MSVCRT_ > - extern unsigned int _winver; > -#else >extern unsigned int * __MINGW_IMP_SYMBOL(_winver); > #define _winver(* __MINGW_IMP_SYMBOL(_winver)) > #endif > -#endif > > #ifndef _winmajor > -#ifdef _MSVCRT_ > - extern unsigned int _winmajor; > -#else >extern unsigned int * __MINGW_IMP_SYMBOL(_winmajor); > #define _winmajor (* __MINGW_IMP_SYMBOL(_winmajor)) > #endif > -#endif > > #ifndef _winminor > -#ifdef _MSVCRT_ > - extern unsigned int _winminor; > -#else >extern unsigned int * __MINGW_IMP_SYMBOL(_winminor); > #define _winminor (* __MINGW_IMP_SYMBOL(_winminor)) > #endif > -#endif > + > +#endif /* !_MSVCRT_ */ > >errno_t __cdecl _get_osplatform(unsigned int *_Value); >
Re: [Mingw-w64-public] [PATCH 0/7] Ucrtbase/__argv/__p___* functions
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 >>> inconsistencies surrounding the build of msvcr* dlls/defs while >>> I was touching that area, cleanly separated in different fixes. >> >> >> >> Thank you for doing that, it looks much better now. >> >> >> BTW, similar solution could be used for other cases where compat is >> questionable otherwise. I'm mostly thinking about providing >> __acrt_iob_func in all libmsvcr* libraries and always using it in >> headers to properly handle stderr and alike. > > > Yes, that might make sense - I think that might fix some other issue I'm > noticing here - where the getopt implementation in libmingwex tries to do > fputc(stderr,) with the non-ucrtbase version of stderr. Yes that sounds like a good approach. Thanks for your work on this, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Define _M_ARM64 just like MSVC does
Patch is okay. Please go ahead ans commit. Thanks Kai Am 07.11.2017 08:42 schrieb "Martin Storsjö" : > Signed-off-by: Martin Storsjö > --- > mingw-w64-headers/crt/_mingw_mac.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/mingw-w64-headers/crt/_mingw_mac.h b/mingw-w64-headers/crt/_ > mingw_mac.h > index eeb59c6..e60e8d7 100644 > --- a/mingw-w64-headers/crt/_mingw_mac.h > +++ b/mingw-w64-headers/crt/_mingw_mac.h > @@ -78,6 +78,10 @@ > # endif > #endif > > +#if defined(__aarch64__) && !defined(_M_ARM64) > +# define _M_ARM64 1 > +#endif > + > #ifndef _X86_ > /* MS does not prefix symbols by underscores for 64-bit. */ > # ifndef __MINGW_USE_UNDERSCORE_PREFIX > -- > 2.7.4 > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] normalise x86 (i686 vs i386) detection
Patch is okay. Please commit. Thanks Kai Am 07.11.2017 08:42 schrieb "Martin Storsjö" : > On Tue, 7 Nov 2017, Martell Malone wrote: > > ping. :) >> I think this is being lost between all the different patches being >> submitted atm. >> > > The patch looks good to me although I'm not very familiar with those > areas. Assuming you've tested it, it looks good to me. > > // Martin > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] headers: Add a configure parameter for setting the default value of _WIN32_WINNT
Hello Martin, The patch is ok. Please go ahead and apply. JonY, Adrien do we have on web-server documentation about our special configure options? I think it might be time to create such a page/document. What do you think? Thanks, Kai 2017-11-03 10:06 GMT+01:00 Martin Storsjö : > Signed-off-by: Martin Storsjö > --- > mingw-w64-headers/configure.ac| 10 ++ > mingw-w64-headers/crt/_mingw.h.in | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac > index 84109c9..21259d3 100644 > --- a/mingw-w64-headers/configure.ac > +++ b/mingw-w64-headers/configure.ac > @@ -152,6 +152,16 @@ AS_VAR_IF([enable_secure_api],[yes], >[MINGW_HAS_SECURE_API=""]) > AC_SUBST([MINGW_HAS_SECURE_API]) > > +AC_MSG_CHECKING([default _WIN32_WINNT version]) > +AC_ARG_WITH([default-win32-winnt], > + [AS_HELP_STRING([--with-default-win32-winnt=VER], > +[Default value of _WIN32_WINNT (default: 0x502)])], > + [], > + [with_default_win32_winnt=0x502]) > +AC_MSG_RESULT([$with_default_win32_winnt]) > +AS_VAR_SET([DEFAULT_WIN32_WINNT],[$with_default_win32_winnt]) > +AC_SUBST([DEFAULT_WIN32_WINNT]) > + > # Checks for typedefs, structures, and compiler characteristics. > > # Checks for library functions. > diff --git a/mingw-w64-headers/crt/_mingw.h.in > b/mingw-w64-headers/crt/_mingw.h.in > index 99373b8..c5f3bf8 100644 > --- a/mingw-w64-headers/crt/_mingw.h.in > +++ b/mingw-w64-headers/crt/_mingw.h.in > @@ -222,7 +222,7 @@ limitations in handling dllimport attribute. */ > > > #ifndef _WIN32_WINNT > -#define _WIN32_WINNT 0x502 > +#define _WIN32_WINNT @DEFAULT_WIN32_WINNT@ > #endif > > #ifndef _INT128_DEFINED > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New bug fix from v5.x release soon
Thanks for the patch. If test passes, patch is ok to apply.
Thanks,
Kai
2017-10-26 14:51 GMT+02:00 Liu Hao :
> On 2017/10/26 19:53, sisyph...@optusnet.com.au wrote:
>>
>> -Original Message- From: JonY via Mingw-w64-public
>> Sent: Thursday, October 26, 2017 10:03 PM
>> To: mingw-w64-public@lists.sourceforge.net
>> Cc: JonY
>> Subject: [Mingw-w64-public] New bug fix from v5.x release soon
>>
>>> Are there any bug fix commits from master that you think should go into
>>> v5.x?
>>> Let me know ASAP, thanks.
>>
>>
>> Is https://sourceforge.net/p/mingw-w64/bugs/478/ being fixed ?
>>
>> It's a bug that has continued to cause me grief over the last couple of
>> years - largely because the perl5 developers have chosen to *not* work
>> around it.
>>
>> Cheers,
>> Rob
>
> The asm statements fail to clobber the AX register so the compiler thinks
> they were left alone and stores a pointer in {R,E}AX.
>
> The attached patch should fix the problem. This is a quick fix and I don't
> have time to test it, please test so we can push this patch before this
> release.
>
>
> --
> Best regards,
> LH_Mouse
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] _ftelli64 bug
Hello, I am not quite sure if this is a Windows bug. The API you are using is actually that one from msvcrt.dll for large/none-large file accesses. The most common issue showing this behavior is the TEXT vs. BINARY file open mode on Windows C-runtime. New-lines might be expanded to carriage-return + new-line, which can change possitions easily. To avoid that use on file open the additional flag O_BINARY. Regards, and I hope this will help you, Kai 2017-10-19 10:06 GMT+02:00 Etienne Sandré-Chardonnal : > Dear all, > > I have a program which reads concurrently multiple files using the C I/O > library. I have encountered a problem, _ftelli64 randomly reports an > incorrect position, with a mismatch of a few bytes. The bug disappears if > any of these changes is done: > >- ftell is used instead of _ftelli64 (but no more large file support) >- std::ifstream is used instead of C functions (but I need _wfopen for >unicode file names) >- files are not read concurrently (reading threads set to 1) > > I have reproduced this in the attached MCVE. It does create 8 files > approximately 3MB large, and reads them concurrently in 8 threads by 65544 > byte blocks. It compares the value returned by fread() and the difference > between _ftelli64 calls before and after fread(). It prints the mismatches. > > Typical output is : > > Error 2.dat / ftell before 3080570 / fread returned 65544 / ftell after > 3146112 / mismatch -2 > > Error 6.dat / ftell before 3080569 / fread returned 65544 / ftell after > 3146112 / mismatch -1 > > Error 4.dat / ftell before 65544 / fread returned 65544 / ftell after > 131089 / mismatch 1 > > Error 5.dat / ftell before 0 / fread returned 65544 / ftell after 65543 / > mismatch -1 > > Error 5.dat / ftell before 65543 / fread returned 65544 / ftell after > 131088 / mismatch 1 > > Error 4.dat / ftell before 2162953 / fread returned 65544 / ftell after > 2228498 / mismatch 1 > > Error 5.dat / ftell before 2162952 / fread returned 65544 / ftell after > 2228497 / mismatch 1 > > Error 4.dat / ftell before 3080570 / fread returned 65544 / ftell after > 3146112 / mismatch -2 > > Error 5.dat / ftell before 3080569 / fread returned 65544 / ftell after > 3146112 / mismatch -1 > > > Is this a bug from windows or from MinGW C library? > > Thanks! > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Fix gendef fallthroughts and enable winpthreads library build
Hello JonY, the winpthread patch is ok. But I have to agree that this "fallthrough feature" of gcc is more or less pretty bad ... Regards, Kai 2017-10-06 15:52 GMT+02:00 JonY via Mingw-w64-public : > Patches OK? > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/3] crt: Add a def file for ucrtbase.dll
Hi, sorry for the late reply. I hope you already pushed it. For completeness: there are no objections from my POV. Thanks, Kai 2017-09-13 10:40 GMT+02:00 Martin Storsjö : > On Mon, 11 Sep 2017, Martin Storsjö wrote: > >> 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. >>> >>> >>> In general, we should use as few compatibility tricks possible for >>> ucrtbase as much as since we can depend on those functions being present >>> in runtime. Having something like you're working on was actually the >>> main reason I moved a lot of compatibility code from mingwex into >>> libmsvcrt.a a few years ago. There are more things that could be moved >>> away from mingwex like that. From your other patch, for example, it >>> looks like we may not need mingw variants of printf/scanf family when >>> targetting ucrtbase, so maybe we could even move them to libmsvcrt.a as >>> well. I'm not sure. >> >> >> Yes, those shouldn't be needed any longer. They aren't used by default at >> all either, unless __USE_MINGW_ANSI_STDIO is defined. If it is, we still use >> our own routines for safety, but if others are ok with it, we can probably >> change it. But it might be easier to make each of those changes a separate >> patch/discussion later, after we've got a first common state merged. >> >>> Anyway, that doesn't have to block integration of your work, but it'd be >>> nice to take into account when doing design decisions. For this patch, >>> just please review those "replaced by emu" cases since they shouldn't be >>> needed for ucrtbase. >> >> >> Sure, I can try to have a look through those and see if I can figure out >> what the situation is. > > > Thanks for pointing these out; I went through all the functions that I had > commented out in this patch, and almost all of them were in replacements in > secapi/* that only was built into libmsvcrt.a but not into the numbered > ones. So after uncommenting those, only a few functions are uncommented > (that are replaced by libmingwex). > > If there's no other comments/objections, I'll push this patchset soon. > > > // Martin > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 08/27] crt: Unify crypt32.def for lib64 and libarm32
Well, I don't think it is necessary to provide them. Thanks, Kai 2017-08-21 15:00 GMT+02:00 Martin Storsjö : > Hi, > > On Mon, 21 Aug 2017, Kai Tietz via Mingw-w64-public wrote: > >> Hello, >> >> I am not sure, if we might have users depending on those ordinal >> import ... I doubt it ... so > > > These are already pushed - OK'd by JonY in > https://sourceforge.net/p/mingw-w64/mailman/message/36003392/. > > If the ordinals were in lib64, there might be a point to it, but in this > case, the unnamed ordinals were in libarm32, so I really doubt anybody are > using it all that seriously yet (since the arm32 target still is unusable > without a patch that isn't yet merged). > > Do you want me to add these ordinals back within an #ifdef DEF_ARM32 block? > > // Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 27/27] crt: Merge lib32's msvcrt.def.in into lib-common
21 up to 27 are ok. Please go ahead and apply to master. Thanks, Kai 2017-08-17 14:14 GMT+02:00 Martin Storsjö : > Where in doubt, where there were non-obvious differences between > the lib32 and lib64 versions, I've kept the definitions separate > instead of trying to unify them too much. (This goes mostly > for the *findfirst/*findnext functions.) > > Some math functions with a -f suffixed float version are available > on all other platforms than i386, so they are marked with > F_NON_I386(). For those functions that are marked DATA on x86 > (where libmingwex provides a replacement on x86), we end up with > markings like "F_NON_I386(cosf F_X86_ANY(DATA))". > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/Makefile.am |2 +- > mingw-w64-crt/lib-common/msvcrt.def.in | 180 - > mingw-w64-crt/lib32/msvcrt.def.in | 1248 > > 3 files changed, 151 insertions(+), 1279 deletions(-) > delete mode 100644 mingw-w64-crt/lib32/msvcrt.def.in > > diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am > index 0f091ca..7ce3c0e 100644 > --- a/mingw-w64-crt/Makefile.am > +++ b/mingw-w64-crt/Makefile.am > @@ -443,7 +443,7 @@ lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32) > $(extra_include) $(AM_CPPFLAGS) > > if !W32API > lib32_LIBRARIES += lib32/libmsvcrt.a > -lib32_libmsvcrt_a_SOURCES = $(src_msvcrt32) lib32/msvcrt.def.in > +lib32_libmsvcrt_a_SOURCES = $(src_msvcrt32) lib-common/msvcrt.def.in > lib32_libmsvcrt_a_AR = $(DTDEF32) lib32/msvcrt.def && $(AR) $(ARFLAGS) > lib32_libmsvcrt_a_CPPFLAGS=$(CPPFLAGS32) -D__LIBMSVCRT__ $(extra_include) > $(sysincludes) > EXTRA_lib32_libmsvcrt_a_DEPENDENCIES=lib32/msvcrt.def > diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in > b/mingw-w64-crt/lib-common/msvcrt.def.in > index 732cb86..c63edd2 100644 > --- a/mingw-w64-crt/lib-common/msvcrt.def.in > +++ b/mingw-w64-crt/lib-common/msvcrt.def.in > @@ -4,6 +4,25 @@ EXPORTS > #include "func.def.in" > #include "msvcrt-common.def.in" > > +#ifdef DEF_I386 > +_CIacos > +_CIasin > +_CIatan > +_CIatan2 > +_CIcos > +_CIcosh > +_CIexp > +_CIfmod > +_CIlog > +_CIlog10 > +_CIpow > +_CIsin > +_CIsinh > +_CIsqrt > +_CItan > +_CItanh > +#endif > + > #ifdef DEF_X64 > $I10_OUTPUT > ; public: __cdecl __non_rtti_object::__non_rtti_object(class > __non_rtti_object const & __ptr64) __ptr64 > @@ -208,6 +227,7 @@ _CrtSetReportHook > _CrtSetReportHook2 > _CrtSetReportMode > _CxxThrowException > +F_I386(_EH_prolog) > _Getdays > _Getmonths > _Gettnames > @@ -221,8 +241,16 @@ _XcptFilter > __AdjustPointer > __C_specific_handler > __CppXcptFilter > +__CxxCallUnwindDtor > +__CxxCallUnwindVecDtor > +__CxxDetectRethrow > +__CxxExceptionFilter > __CxxFrameHandler > __CxxFrameHandler3 > +F_I386(__CxxLongjmpUnwind) > +__CxxQueryExceptionSize > +__CxxRegisterExceptionObject > +__CxxUnregisterExceptionObject > __DestructExceptionObject > __RTCastToVoid > __RTDynamicCast > @@ -237,6 +265,7 @@ ___unguarded_readlc_active_add_func > __argc DATA > __argv DATA > __badioinfo DATA > +F_I386(__buffer_overrun) > __crtCompareStringA > __crtCompareStringW > __crtGetLocaleInfoW > @@ -254,23 +283,56 @@ __iob_func > __isascii > __iscsym > __iscsymf > +__lc_clike > __lc_codepage DATA > __lc_collate_cp DATA > __jump_unwind > __lc_handle DATA > __lconv_init > __mb_cur_max DATA > +__p___argc > +__p___argv > +__p___initenv > +__p___mb_cur_max > +__p___wargv > +__p___winitenv > +__p__acmdln > +__p__amblksiz > +__p__commode > +__p__daylight > +__p__dstbias > +__p__environ > +__p__fileinfo > +__p__fmode > +__p__iob > +__p__mbcasemap > +__p__mbctype > +__p__osver > +__p__pctype > +__p__pgmptr > +__p__pwctype > +__p__timezone > +__p__tzname > +__p__wcmdln > +__p__wenviron > +__p__winmajor > +__p__winminor > +__p__winver > +__p__wpgmptr > __pctype_func > __pioinfo DATA > __pwctype_func > __pxcptinfoptrs > +__security_error_handler > __set_app_type > +__set_buffer_overrun_handler > __setlc_active DATA > __setusermatherr > __strncnt > __threadhandle > __threadid > __toascii > +__uncaught_exception > __unDName > __unDNameEx > __unguarded_readlc_active DATA > @@ -280,10 +342,27 @@ __wcserror_s > __wcsncnt > __wgetmainargs > F_X86_ANY(__winitenv DATA) > +_abnormal_termination > _abs64 > _access > ; _access_s Replaced by emu > _acmdln DATA > +#ifdef DEF_I386 > +_adj_fdiv_m16i > +_adj_fdiv_m32 > +_adj_fdiv_m32i > +_adj_fdiv_m64 > +_adj_fdiv_r > +_adj_fdivr_m16i > +_adj_fdivr_m32 > +_adj_fdivr_m32i > +_adj_fdivr_m64 > +_adj_fpatan > +_adj_fprem > +_adj_fprem1 > +_adj_fptan > +_adjust_fdiv DATA > +#endif > _aexit_rtn DATA > _aligned_free > _aligned_free_dbg > @@ -324,6 +403,7 @@ _chdrive > _chgsign > _chgsignf > _chmod > +_chkesp > _chsize > ; _chsize_s replaced by emu > _chvalidator > @@ -345,6 +425,7 @@ _cprintf_p_l > ; _cprintf_s_l likewise. > _cputs > _cputws > +_CRT_RTC_INIT > _creat > _create_locale > _crtAssertBusy > @@ -358,7 +439,7 @@ _ctime32 >
Re: [Mingw-w64-public] [PATCH 20/27] crt: Unify rpcrt4.def for lib64 and libarm32
Patches 11 up to 20 are looking fine. Please apply.
Thanks,
Kai
2017-08-17 14:14 GMT+02:00 Martin Storsjö :
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/{lib64 => lib-common}/rpcrt4.def | 36 +-
> mingw-w64-crt/libarm32/rpcrt4.def | 534
> -
> 2 files changed, 31 insertions(+), 539 deletions(-)
> rename mingw-w64-crt/{lib64 => lib-common}/rpcrt4.def (93%)
> delete mode 100644 mingw-w64-crt/libarm32/rpcrt4.def
>
> diff --git a/mingw-w64-crt/lib64/rpcrt4.def
> b/mingw-w64-crt/lib-common/rpcrt4.def
> similarity index 93%
> rename from mingw-w64-crt/lib64/rpcrt4.def
> rename to mingw-w64-crt/lib-common/rpcrt4.def
> index adeb75f..4be11bc 100644
> --- a/mingw-w64-crt/lib64/rpcrt4.def
> +++ b/mingw-w64-crt/lib-common/rpcrt4.def
> @@ -1,16 +1,17 @@
> -;
> -; Definition file of RPCRT4.dll
> -; Automatic generated by gendef
> -; written by Kai Tietz 2008
> -;
> LIBRARY "RPCRT4.dll"
> EXPORTS
> CreateProxyFromTypeInfo
> CreateStubFromTypeInfo
> I_RpcFixTransferSyntax
> +I_RpcBindingInqCurrentModifiedId
> I_RpcFwThisIsTheManager
> +I_RpcInitFwImports
> I_RpcInitHttpImports
> +I_RpcInitImports
> +I_RpcInitNdrImports
> +I_RpcMgmtQueryDedicatedThreadPool
> I_RpcOpenClientProcess
> +I_RpcOpenClientThread
> I_RpcServerTurnOnOffKeepalives
> I_RpcVerifierCorruptionExpected
> NdrFullPointerFree
> @@ -18,7 +19,12 @@ NdrFullPointerInsertRefId
> NdrFullPointerQueryPointer
> NdrFullPointerQueryRefId
> NdrGetBaseInterfaceFromStub
> +NdrpClientCall2
> RpcCertMatchPrincipalName
> +pfnFreeRoutines DATA
> +pfnMarshallRoutines DATA
> +pfnSizeRoutines DATA
> +pfnUnmarshallRoutines DATA
> CStdStubBuffer_AddRef
> CStdStubBuffer_Connect
> CStdStubBuffer_CountRefs
> @@ -49,6 +55,7 @@ I_RpcBCacheFree
> I_RpcBindingCopy
> I_RpcBindingCreateNP
> I_RpcBindingHandleToAsyncHandle
> +I_RpcBindingInqClientTokenAttributes
> I_RpcBindingInqConnId
> I_RpcBindingInqDynamicEndpoint
> I_RpcBindingInqDynamicEndpointA
> @@ -60,8 +67,12 @@ I_RpcBindingInqSecurityContextKeyInfo
> I_RpcBindingInqTransportType
> I_RpcBindingInqWireIdForSnego
> I_RpcBindingIsClientLocal
> +I_RpcBindingIsServerLocal
> +I_RpcBindingSetPrivateOption
> I_RpcBindingToStaticStringBindingW
> +I_RpcCertProcessAndProvision
> I_RpcClearMutex
> +I_RpcCompleteAndFree
> I_RpcConnectionInqSockBuffSize
> I_RpcConnectionSetSockBuffSize
> I_RpcCompleteAndFree
> @@ -75,12 +86,14 @@ I_RpcFreePipeBuffer
> I_RpcGetBuffer
> I_RpcGetBufferWithObject
> I_RpcGetCurrentCallHandle
> +I_RpcGetDefaultSD
> I_RpcGetExtendedError
> I_RpcGetPortAllocationData
> I_RpcIfInqTransferSyntaxes
> I_RpcLogEvent
> I_RpcMapWin32Status
> I_RpcMarshalBindingHandleAndInterfaceForNDF
> +I_RpcMgmtEnableDedicatedThreadPool
> I_RpcNDRCGetWireRepresentation
> I_RpcNDRSContextEmergencyCleanup
> I_RpcNegotiateTransferSyntax
> @@ -89,6 +102,7 @@ I_RpcNsBindingSetEntryNameA
> I_RpcNsBindingSetEntryNameW
> I_RpcNsInterfaceExported
> I_RpcNsInterfaceUnexported
> +I_RpcOpenClientProcess
> I_RpcParseSecurity
> I_RpcPauseExecution
> I_RpcProxyNewConnection
> @@ -102,6 +116,8 @@ I_RpcSend
> I_RpcSendReceive
> I_RpcServerAllocateIpPort
> I_RpcServerCheckClientRestriction
> +I_RpcServerDisableExceptionFilter
> +I_RpcServerGetAssociationID
> I_RpcServerInqAddressChangeFn
> I_RpcServerInqLocalConnAddress
> I_RpcServerInqRemoteConnAddress
> @@ -110,6 +126,7 @@ I_RpcServerIsClientDisconnected
> I_RpcServerRegisterForwardFunction
> I_RpcServerSetAddressChangeFn
> I_RpcServerStartService
> +I_RpcServerSubscribeForDisconnectNotification
> I_RpcServerUseProtseq2A
> I_RpcServerUseProtseq2W
> I_RpcServerUseProtseqEp2A
> @@ -235,6 +252,7 @@ NdrFullPointerQueryPointer
> NdrFullPointerQueryRefId
> NdrFullPointerXlatFree
> NdrFullPointerXlatInit
> +NdrGetBaseInterfaceFromStub
> NdrGetBuffer
> NdrGetDcomProtocolVersion
> NdrGetSimpleTypeBufferAlignment
> @@ -426,6 +444,7 @@ RpcGetAuthorizationContextForClient
> RpcIfIdVectorFree
> RpcIfInqId
> RpcImpersonateClient
> +RpcImpersonateClient2
> RpcInitializeAsyncHandle
> RpcMgmtEnableIdleCleanup
> RpcMgmtEpEltInqBegin
> @@ -470,11 +489,18 @@ RpcServerInqCallAttributesW
> RpcServerInqDefaultPrincNameA
> RpcServerInqDefaultPrincNameW
> RpcServerInqIf
> +RpcServerInterfaceGroupActivate
> +RpcServerInterfaceGroupClose
> +RpcServerInterfaceGroupCreateA
> +RpcServerInterfaceGroupCreateW
> +RpcServerInterfaceGroupDeactivate
> +RpcServerInterfaceGroupInqBindings
> RpcServerListen
> RpcServerRegisterAuthInfoA
> RpcServerRegisterAuthInfoW
&
Re: [Mingw-w64-public] [PATCH 06/27] crt: Unify bcrypt.def for lib64 and libarm32
Patch files 04 up to 10 are ok. Please go ahead and apply.
Thanks,
Kai
2017-08-17 14:14 GMT+02:00 Martin Storsjö :
> Keep functions from both previous versions.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/{lib64 => lib-common}/bcrypt.def | 8 ++--
> mingw-w64-crt/libarm32/bcrypt.def | 64
> --
> 2 files changed, 3 insertions(+), 69 deletions(-)
> rename mingw-w64-crt/{lib64 => lib-common}/bcrypt.def (93%)
> delete mode 100644 mingw-w64-crt/libarm32/bcrypt.def
>
> diff --git a/mingw-w64-crt/lib64/bcrypt.def
> b/mingw-w64-crt/lib-common/bcrypt.def
> similarity index 93%
> rename from mingw-w64-crt/lib64/bcrypt.def
> rename to mingw-w64-crt/lib-common/bcrypt.def
> index 6aad7b0..5415bad 100644
> --- a/mingw-w64-crt/lib64/bcrypt.def
> +++ b/mingw-w64-crt/lib-common/bcrypt.def
> @@ -1,8 +1,3 @@
> -;
> -; Definition file of bcrypt.dll
> -; Automatic generated by gendef
> -; written by Kai Tietz 2008
> -;
> LIBRARY "bcrypt.dll"
> EXPORTS
> BCryptAddContextFunction
> @@ -12,6 +7,7 @@ BCryptConfigureContext
> BCryptConfigureContextFunction
> BCryptCreateContext
> BCryptCreateHash
> +BCryptCreateMultiHash
> BCryptDecrypt
> BCryptDeleteContext
> BCryptDeriveKey
> @@ -41,7 +37,9 @@ BCryptGetProperty
> BCryptHashData
> BCryptImportKey
> BCryptImportKeyPair
> +BCryptKeyDerivation
> BCryptOpenAlgorithmProvider
> +BCryptProcessMultiOperations
> BCryptQueryContextConfiguration
> BCryptQueryContextFunctionConfiguration
> BCryptQueryContextFunctionProperty
> diff --git a/mingw-w64-crt/libarm32/bcrypt.def
> b/mingw-w64-crt/libarm32/bcrypt.def
> deleted file mode 100644
> index e6ab26d..000
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 03/27] crt: Share a def file where lib64 has got a superset of the functions in libarm32
Hi,
patch is ok.
Thanks,
Kai
2017-08-17 14:14 GMT+02:00 Martin Storsjö :
> Include the C++ function definitions only on x86_64, since they were
> only present in the lib64 def file.
>
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/Makefile.am | 6 ++--
> .../clbcatq.def => lib-common/clbcatq.def.in} | 34 ++---
> mingw-w64-crt/libarm32/clbcatq.def | 35
> --
> 3 files changed, 19 insertions(+), 56 deletions(-)
> rename mingw-w64-crt/{lib64/clbcatq.def => lib-common/clbcatq.def.in} (73%)
> delete mode 100644 mingw-w64-crt/libarm32/clbcatq.def
>
> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
> index 2d33152..3566322 100644
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -894,7 +894,8 @@ lib64_libmingwthrd_a_CPPFLAGS=$(CPPFLAGS64) $(sysincludes)
>
> processed_defs += lib64/msvcrt.def lib64/msvcr80.def lib64/msvcr90.def
> lib64/msvcr90d.def \
> lib64/msvcr100.def lib64/msvcr110.def
> lib64/msvcr120.def lib64/msvcr120d.def \
> - lib64/msvcr120_app.def
> lib64/msvcp120_app.def
> + lib64/msvcr120_app.def
> lib64/msvcp120_app.def \
> + lib64/clbcatq.def
>
> endif
>
> @@ -1187,7 +1188,8 @@ libarm32_LIBRARIES += libarm32/libmingwthrd.a
> libarm32_libmingwthrd_a_SOURCES = $(src_libmingwthrd)
> libarm32_libmingwthrd_a_CPPFLAGS=$(CPPFLAGSARM32) $(sysincludes)
>
> -processed_defs += libarm32/msvcrt.def libarm32/msvcr80.def
> libarm32/msvcr90.def libarm32/msvcr90d.def libarm32/msvcr100.def
> libarm32/msvcr110.def
> +processed_defs += libarm32/msvcrt.def libarm32/msvcr80.def
> libarm32/msvcr90.def libarm32/msvcr90d.def libarm32/msvcr100.def
> libarm32/msvcr110.def \
> + libarm32/clbcatq.def
>
> endif
>
> diff --git a/mingw-w64-crt/lib64/clbcatq.def
> b/mingw-w64-crt/lib-common/clbcatq.def.in
> similarity index 73%
> rename from mingw-w64-crt/lib64/clbcatq.def
> rename to mingw-w64-crt/lib-common/clbcatq.def.in
> index a50196e..78b6981 100644
> --- a/mingw-w64-crt/lib64/clbcatq.def
> +++ b/mingw-w64-crt/lib-common/clbcatq.def.in
> @@ -1,42 +1,38 @@
> -;
> -; Exports of file CLBCatQ.DLL
> -;
> -; Autogenerated by gen_exportdef
> -; Written by Kai Tietz, 2007
> -;
> +#include "func.def.in"
> +
> LIBRARY CLBCatQ.DLL
> EXPORTS
> ActivatorUpdateForIsRouterChanges
> ; void __cdecl ClearList(class CStructArray * __ptr64)
> -?ClearList@@YAXPEAVCStructArray@@@Z
> +F_X64(?ClearList@@YAXPEAVCStructArray@@@Z)
> CoRegCleanup
> ; long __cdecl CreateComponentLibraryTS(unsigned short const *
> __ptr64,long,struct IComponentRecords * __ptr64 * __ptr64)
> -?CreateComponentLibraryTS@@YAJPEBGJPEAPEAUIComponentRecords@@@Z
> +F_X64(?CreateComponentLibraryTS@@YAJPEBGJPEAPEAUIComponentRecords@@@Z)
> ; long __cdecl DataConvert(unsigned short,unsigned short,unsigned
> long,unsigned long * __ptr64,void * __ptr64,void * __ptr64,unsigned
> long,unsigned long,unsigned long * __ptr64,unsigned char,unsigned
> char,unsigned long)
> -?DataConvert@@YAJGGKPEAKPEAX1KK0EEK@Z
> +F_X64(?DataConvert@@YAJGGKPEAKPEAX1KK0EEK@Z)
> DeleteAllActivatorsForClsid
> ; void __cdecl DestroyStgDatabase(class StgDatabase * __ptr64)
> -?DestroyStgDatabase@@YAXPEAVStgDatabase@@@Z
> +F_X64(?DestroyStgDatabase@@YAXPEAVStgDatabase@@@Z)
> DowngradeAPL
> ; long __cdecl GetDataConversion(struct IDataConvert * __ptr64 * __ptr64)
> -?GetDataConversion@@YAJPEAPEAUIDataConvert@@@Z
> +F_X64(?GetDataConversion@@YAJPEAPEAUIDataConvert@@@Z)
> ; class CGetDataConversion * __ptr64 __cdecl GetDataConvertObject(void)
> -?GetDataConvertObject@@YAPEAVCGetDataConversion@@XZ
> +F_X64(?GetDataConvertObject@@YAPEAVCGetDataConversion@@XZ)
> GetGlobalBabyJITEnabled
> ; long __cdecl GetPropValue(unsigned short,long * __ptr64,void *
> __ptr64,int,int * __ptr64,struct tagDBPROP & __ptr64)
> -?GetPropValue@@YAJGPEAJPEAXHPEAHAEAUtagDBPROP@@@Z
> +F_X64(?GetPropValue@@YAJGPEAJPEAXHPEAHAEAUtagDBPROP@@@Z)
> ; long __cdecl GetStgDatabase(class StgDatabase * __ptr64 * __ptr64)
> -?GetStgDatabase@@YAJPEAPEAVStgDatabase@@@Z
> +F_X64(?GetStgDatabase@@YAJPEAPEAVStgDatabase@@@Z)
> ; void __cdecl InitErrors(unsigned long * __ptr64)
> -?InitErrors@@YAXPEAK@Z
> +F_X64(?InitErrors@@YAXPEAK@Z)
> ; long __cdecl OpenComponentLibrarySharedTS(unsigned short const *
> __ptr64,unsigned short const * __ptr64,unsigned long,struct
> _SECURITY_ATTRIBUTES * __ptr64,long,struct IComponentRecords * __ptr64 *
> __ptr64)
> -?OpenComponentLi
Re: [Mingw-w64-public] [PATCH 08/27] crt: Unify crypt32.def for lib64 and libarm32
Hello,
I am not sure, if we might have users depending on those ordinal
import ... I doubt it ... so
02 - 03 patches are ok. Please go ahead and apply.
Thanks,
Ka
2017-08-17 14:14 GMT+02:00 Martin Storsjö :
> Signed-off-by: Martin Storsjö
> ---
> mingw-w64-crt/{libarm32 => lib-common}/crypt32.def | 23 +-
> mingw-w64-crt/lib64/crypt32.def| 273
> -
> 2 files changed, 6 insertions(+), 290 deletions(-)
> rename mingw-w64-crt/{libarm32 => lib-common}/crypt32.def (96%)
> delete mode 100644 mingw-w64-crt/lib64/crypt32.def
>
> diff --git a/mingw-w64-crt/libarm32/crypt32.def
> b/mingw-w64-crt/lib-common/crypt32.def
> similarity index 96%
> rename from mingw-w64-crt/libarm32/crypt32.def
> rename to mingw-w64-crt/lib-common/crypt32.def
> index 81b8f7a..3b81bcd 100644
> --- a/mingw-w64-crt/libarm32/crypt32.def
> +++ b/mingw-w64-crt/lib-common/crypt32.def
> @@ -1,21 +1,9 @@
> -;
> -; Definition file of CRYPT32.dll
> -; Automatic generated by gendef
> -; written by Kai Tietz 2008-2014
> -;
> LIBRARY "CRYPT32.dll"
> EXPORTS
> -ord_1001 @1001
> -ord_1002 @1002
> -ord_1003 @1003
> -ord_1004 @1004
> -ord_1005 @1005
> -ord_1006 @1006
> -ord_1007 @1007
> -ord_1008 @1008
> -ord_1009 @1009
> -ord_1010 @1010
> -ord_1011 @1011
> +ChainWlxLogoffEvent
> +CloseCertPerformanceData
> +CollectCertPerformanceData
> +OpenCertPerformanceData
> CryptObjectLocatorFree
> CryptObjectLocatorGet
> CryptObjectLocatorGetContent
> @@ -180,6 +168,8 @@ CryptGetMessageCertificates
> CryptGetMessageSignerCount
> CryptGetOIDFunctionAddress
> CryptGetOIDFunctionValue
> +CryptGetDefaultProviderA
> +CryptGetDefaultProviderW
> CryptHashCertificate
> CryptHashCertificate2
> CryptHashMessage
> @@ -303,4 +293,3 @@ PFXExportCertStoreEx
> PFXImportCertStore
> PFXIsPFXBlob
> PFXVerifyPassword
> -ord_2000 @2000
> diff --git a/mingw-w64-crt/lib64/crypt32.def b/mingw-w64-crt/lib64/crypt32.def
> deleted file mode 100644
> index 2e2f352..000
> --
> 2.7.4
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 01/27] crt: Include the def file in libwindowscodecs.a
Hello, patch is ok. Please go ahead and apply. Thanks, Kai 2017-08-17 14:14 GMT+02:00 Martin Storsjö : > Previously, we didn't actually ever include the def file in this library. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/Makefile.am | 3 +++ > mingw-w64-crt/lib32/Makefile.am| 1 - > mingw-w64-crt/libarm32/Makefile.am | 1 - > 3 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am > index 1600ac2..b6c0f43 100644 > --- a/mingw-w64-crt/Makefile.am > +++ b/mingw-w64-crt/Makefile.am > @@ -491,6 +491,7 @@ lib32_libwmcodecdspuuid_a_CPPFLAGS = $(CPPFLAGS32) > $(sysincludes) > lib32_LIBRARIES += lib32/libwindowscodecs.a > lib32_libwindowscodecs_a_SOURCES = $(src_libwindowscodecs) > lib32_libwindowscodecs_a_CPPFLAGS = $(CPPFLAGS32) $(sysincludes) > +lib32_libwindowscodecs_a_AR = $(DTDEF32) > $(top_srcdir)/lib32/windowscodecs.def && $(AR) $(ARFLAGS) > > lib32_LIBRARIES += lib32/libwbemuuid.a > lib32_libwbemuuid_a_SOURCES = $(src_libwbemuuid) > @@ -790,6 +791,7 @@ lib64_libwmcodecdspuuid_a_CPPFLAGS = $(CPPFLAGS64) > $(sysincludes) > lib64_LIBRARIES += lib64/libwindowscodecs.a > lib64_libwindowscodecs_a_SOURCES = $(src_libwindowscodecs) > lib64_libwindowscodecs_a_CPPFLAGS = $(CPPFLAGS64) $(sysincludes) > +lib64_libwindowscodecs_a_AR = $(DTDEF64) > $(top_srcdir)/lib-common/windowscodecs.def && $(AR) $(ARFLAGS) > > lib64_LIBRARIES += lib64/libwbemuuid.a > lib64_libwbemuuid_a_SOURCES = $(src_libwbemuuid) > @@ -1088,6 +1090,7 @@ libarm32_libwmcodecdspuuid_a_CPPFLAGS = > $(CPPFLAGSARM32) $(sysincludes) > libarm32_LIBRARIES += libarm32/libwindowscodecs.a > libarm32_libwindowscodecs_a_SOURCES = $(src_libwindowscodecs) > libarm32_libwindowscodecs_a_CPPFLAGS = $(CPPFLAGSARM32) $(sysincludes) > +libarm32_libwindowscodecs_a_AR = $(DTDEFARM32) > $(top_srcdir)/lib-common/windowscodecs.def && $(AR) $(ARFLAGS) > > libarm32_LIBRARIES += libarm32/libwbemuuid.a > libarm32_libwbemuuid_a_SOURCES = $(src_libwbemuuid) > diff --git a/mingw-w64-crt/lib32/Makefile.am b/mingw-w64-crt/lib32/Makefile.am > index f04a5b2..adf4c07 100644 > --- a/mingw-w64-crt/lib32/Makefile.am > +++ b/mingw-w64-crt/lib32/Makefile.am > @@ -284,7 +284,6 @@ lib32_DATA += %reldir%/libwevtfwd.a > lib32_DATA += %reldir%/libwiadss.a > lib32_DATA += %reldir%/libwin32k.a > lib32_DATA += %reldir%/libwin32spl.a > -lib32_DATA += %reldir%/libwindowscodecs.a > lib32_DATA += %reldir%/libwinhttp.a > lib32_DATA += %reldir%/libwininet.a > lib32_DATA += %reldir%/libwinmm.a > diff --git a/mingw-w64-crt/libarm32/Makefile.am > b/mingw-w64-crt/libarm32/Makefile.am > index aeb9e75..10a4b96 100644 > --- a/mingw-w64-crt/libarm32/Makefile.am > +++ b/mingw-w64-crt/libarm32/Makefile.am > @@ -886,7 +886,6 @@ libarm32_DATA += %reldir%/libwimgapi.a > libarm32_DATA += %reldir%/libwinbici.a > libarm32_DATA += %reldir%/libwinbio.a > libarm32_DATA += %reldir%/libwinbrand.a > -libarm32_DATA += %reldir%/libwindowscodecs.a > libarm32_DATA += %reldir%/libwindowscodecsext.a > libarm32_DATA += %reldir%/libwindows.data.pdf.a > libarm32_DATA += %reldir%/libwindows.globalization.fontgroups.a > -- > 2.7.4 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files
2017-08-09 15:11 GMT+02:00 Martell Malone : >> >> Just out of curiosity - the 800 def files that only are available for >> x86_64 but not for i686, are they something that somebody practically care >> about? Should we try to add them to i686 as well (given that they probably >> actually exist there as well)? Do they serve any real purpose? > > > I don't want to put this on you for this patch but while we are on this > discussion, I want to bring the issue up. > The same thing should apply to x64 and x86 also. > binutils dlltool and mingw-w64 does some weird wrapping of the `_` for x86 > to make it appear more like x64 symbols that is not done by msvc lib.exe > and the msvc headers. > We would ideally update dlltool and mingw-w64 to not do this anymore. > > In llvm I left room to easily enable and disable this for llvm-dlltool > https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Object/COFFModuleDefinition.h#L48 > > I talked to Rui a little bit before about adding a flag for llvm-dlltool to > disable this > The same flag should be added to dlltool so that we can share def files > between all 4 targets. > > For the rest, I guess it needs more or less manual labour to sort out the >> differences into some sort of template like what I described. The i686 ones >> with stdcall probably aren't mergeable at all, unless we do even more >> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4). > > If I remember correctly, I will have to reconfirm though we should not need > the @ for short import libraries but binutils dlltool doesn't use short > import libs. :( > ld supports them however.. even though it does not support the PE/COFF Aux > spec 3 for weak externals i.e. the `==` functions in llvm-dlltool > So there are 3 issues here at least for sharing i686 with the rest. Right, and we have to consider backward compatibility about mangled stuff ... > With that in mind it might be a good idea just to share the other 3 for now > leaving i686 as is? Yes, I think we should keep x86 separate. It is pretty painful to support all this nasty x86 symbol decoration stuff in a compatible way for the other 3 architectures. Nevertheless llvm-dlltool should learn at least the '==' aliasing. We rely on it in our runtime, so I think it would be pretty helpful. Regards, Kai > > > > On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö wrote: > >> On Wed, 9 Aug 2017, Jacek Caban wrote: >> >> On 08.08.2017 22:32, Martin Storsjö wrote: >>> The libarm64 directory is a copy of libarm32 with minimal modifications (renamings in the *.mri scripts and in Makefile.am). >>> >>> >>> In that case I don't think we should have actual copies of every single >>> .def file. It should be possible to use the same files for both >>> platforms by simply modifying Makefile.am. Maybe we should have libarm/ >>> for common files and then libarm32/ and libarm64/ for things that >>> differ? I'm not sure about the exact solution, but I think we should >>> share those one way or another. >>> >> >> That'd probably be a good idea - the size of the total amount of def files >> is staggering. There's >1100 def files in libarm32 weighing in over 7 MB. >> This patch, generated with git format-patch -C, is even 400 KB, just to >> describe the copied files... lib64 also has got about as many files, while >> lib32 only has got a bit over 300 files. >> >> Just out of curiosity - the 800 def files that only are available for >> x86_64 but not for i686, are they something that somebody practically care >> about? Should we try to add them to i686 as well (given that they probably >> actually exist there as well)? Do they serve any real purpose? >> >> >> That said, most DLLs probably are mostly identical, but some might have >> minor differences. Ideally these should be dumped from real DLL files, just >> like on previous platforms, but since platform isn't really available yet, >> it's not really doable, so I started out with the one that is most probable >> to be similar, and then meant to add other changes on top once we know more >> details. >> >> Ideally we'd do something like wine, with minor arch annotations in the >> spec files for the few functions that differ. Perhaps something with CPP >> macros, like we already have for def-include/msvcrt-common.def.in - with >> macros like FUNC_ARM_ARM64(fabsf) or something such. >> >> I guess the first step would be to try to compare what we have and unify >> those that are easily mergeable (that already are identical). Hopefully >> that'd be the vast majority of them. >> >> For the rest, I guess it needs more or less manual labour to sort out the >> differences into some sort of template like what I described. The i686 ones >> with stdcall probably aren't mergeable at all, unless we do even more >> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection, @4). >> >> // Martin -- Check out the
Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files
2017-08-09 14:34 GMT+02:00 Jacek Caban : > On 08.08.2017 22:32, Martin Storsjö wrote: >> The libarm64 directory is a copy of libarm32 with minimal modifications >> (renamings in the *.mri scripts and in Makefile.am). > > > In that case I don't think we should have actual copies of every single > .def file. It should be possible to use the same files for both > platforms by simply modifying Makefile.am. Maybe we should have libarm/ > for common files and then libarm32/ and libarm64/ for things that > differ? I'm not sure about the exact solution, but I think we should > share those one way or another. Agreed. We should try to share those parts. And just keep those files separate, which are different. We could also think about running some sed/preprocess/... on it, and have them within on file. I am open for any solution here. Cheers, Kai > > Thanks, > > Jacek -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add the sincos* functions on arm, calling into sin/cos separately
Hmm,
is there a chance that this source file is used for none ARM? If so,
we should reject this on top, as other targets (the exisiting ones)
are already providing this function.
Otherwise patch looks ok for me too.
Regards,
Kai
2017-08-03 0:48 GMT+02:00 JonY via Mingw-w64-public
:
> On 07/30/2017 07:45 PM, Martin Storsjö wrote:
>> On arm (unless --enable-experimental=softmath is set), we pass
>> sin/cos function calls straight through to msvcrt. We normally
>> provide implementations of the sincos family of functions, that
>> provide both return values at once. Provide implementations of
>> these functions that simply call the sin/cos functions.
>
> Looks OK to me.
>
>> ---
>> mingw-w64-crt/Makefile.am | 2 +-
>> mingw-w64-crt/math/arm/sincos.c | 29 +
>> 2 files changed, 30 insertions(+), 1 deletion(-)
>> create mode 100644 mingw-w64-crt/math/arm/sincos.c
>>
>> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
>> index 83dbdf6..549b4a9 100644
>> --- a/mingw-w64-crt/Makefile.am
>> +++ b/mingw-w64-crt/Makefile.am
>> @@ -351,7 +351,7 @@ src_libmingwexarm32=\
>>math/softmath/sinf.c math/softmath/sinl.c math/softmath/tanf.c
>> math/softmath/tanl.c
>> else
>> src_libmingwexarm32=\
>> - math/arm/exp2.c math/arm/log2.c math/arm/scalbn.c
>> + math/arm/exp2.c math/arm/log2.c math/arm/scalbn.c
>> math/arm/sincos.c
>> endif
>>
>>
>> diff --git a/mingw-w64-crt/math/arm/sincos.c
>> b/mingw-w64-crt/math/arm/sincos.c
>> new file mode 100644
>> index 000..3bb86ee
>> --- /dev/null
>> +++ b/mingw-w64-crt/math/arm/sincos.c
>> @@ -0,0 +1,29 @@
>> +/**
>> + * This file has no copyright assigned and is placed in the Public Domain.
>> + * This file is part of the mingw-w64 runtime package.
>> + * No warranty is given; refer to the file DISCLAIMER.PD within this
>> package.
>> + */
>> +
>> +#include
>> +
>> +void sincos (double __x, double *p_sin, double *p_cos)
>> +{
>> + *p_sin = sin(__x);
>> + *p_cos = cos(__x);
>> +}
>> +
>> +void sincosf (float __x, float *p_sin, float *p_cos)
>> +{
>> + *p_sin = sinf(__x);
>> + *p_cos = cosf(__x);
>> +}
>> +
>> +void sincosl (long double __x, long double *p_sin, long double *p_cos)
>> +{
>> +#if defined(__arm__) || defined(_ARM_)
>> + *p_sin = sin(__x);
>> + *p_cos = cos(__x);
>> +#else
>> +#error Not supported on your platform yet
>> +#endif
>> +}
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winbase.h: WaitForMultipleObjects is available on UWP
Hello Hugo,
Hmm, I am not that convinced that this patch is ok. Why is just W4MO
a general import? Are you sure that in App mode this function has be
present too? Do you have some pointers for this?
Regards,
Kai
2017-07-10 17:06 GMT+02:00 Hugo Beauzée-Luyssen :
> On Tue, Jun 27, 2017, at 05:44 PM, Hugo Beauzée-Luyssen wrote:
>> ---
>> mingw-w64-headers/include/winbase.h | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/mingw-w64-headers/include/winbase.h
>> b/mingw-w64-headers/include/winbase.h
>> index 74bc512c..be050cc6 100644
>> --- a/mingw-w64-headers/include/winbase.h
>> +++ b/mingw-w64-headers/include/winbase.h
>> @@ -1265,6 +1265,10 @@ extern "C" {
>> #define CRITICAL_SECTION_NO_DEBUG_INFO
>> RTL_CRITICAL_SECTION_FLAG_NO_DEBUG_INFO
>> #endif
>>
>> +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) || _WIN32_WINNT
>> >= _WIN32_WINNT_WIN10
>> + WINBASEAPI DWORD WINAPI WaitForMultipleObjects (DWORD nCount, CONST
>> HANDLE *lpHandles, WINBOOL bWaitAll, DWORD dwMilliseconds);
>> +#endif
>> +
>> #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
>>typedef enum _DEP_SYSTEM_POLICY_TYPE {
>> DEPPolicyAlwaysOff = 0,
>> @@ -1286,7 +1290,6 @@ extern "C" {
>> #define SET_TAPE_DRIVE_INFORMATION 1
>>
>>WINBASEAPI WINBOOL WINAPI PulseEvent (HANDLE hEvent);
>> - WINBASEAPI DWORD WINAPI WaitForMultipleObjects (DWORD nCount, CONST
>> HANDLE *lpHandles, WINBOOL bWaitAll, DWORD dwMilliseconds);
>>WINBASEAPI ATOM WINAPI GlobalDeleteAtom (ATOM nAtom);
>>WINBASEAPI WINBOOL WINAPI InitAtomTable (DWORD nSize);
>>WINBASEAPI ATOM WINAPI DeleteAtom (ATOM nAtom);
>> --
>> 2.11.0
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> Ping for review :)
>
> Regards,
>
> --
> Hugo Beauzée-Luyssen
> h...@beauzee.fr
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] VirtualProtect problem in pseudo-reloc.c
Hi, yes, the patch looks fine to me. Your changes looking fine to me. Nevertheless we should just put this code change just in master, as we need to let people test new code. Please go ahead and commit to master. Thanks, Kai 2017-07-09 21:25 GMT+02:00 Arthur D. Edelstein : > Turns out I could remove one more line, because a local variable > becomes unused. Here is a revised patch. > > On Sat, Jul 8, 2017 at 11:18 PM, Arthur D. Edelstein > wrote: >> It seems my patch attachment was maybe blocked. Here it is again with >> a .txt extension. >> >> On Sat, Jul 8, 2017 at 11:06 PM, Arthur D. Edelstein >> wrote: >>> Hi, I am proposing a patch here to deal with a problem found in a >>> cross-compiled Tor Browser and Tor Expert Bundle. Using VMMap on >>> Windows, we observed Execute/Read/Write (XRW) and >>> Execute/Copy-on-Write pages (X/COW) in some DLLs and the Tor >>> executable, even though the .text sections for these binaries were >>> marked with the Execute/Read-only (XR) flag. Obviously this is >>> undesirable from a security viewpoint. >>> >>> So I used WinDbg to try to see what was happening. The problem was >>> caused by VirtualProtect calls in pseudo-reloc.c. Here is an example >>> in zlib1.dll (one of the DLLs bundled with tor.exe): >>> >>> Just before VirtualProtect runs, we have the following executable region: >>> >>> 706c1000 706d400013000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ >>> >>> Then mark_section_writable calls VirtualProtect at 706C1000 to XRW and we >>> get: >>> >>> 706c1000 706d200011000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_WRITECOPY >>> 706d2000 706d3000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READWRITE >>> 706d3000 706d4000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_WRITECOPY >>> >>> It's odd that some pages are XRW (as requested) but some are X/COW. >>> Perhaps using X/COW is a Microsoft strategy to conserve memory. >>> >>> In any case, just before the restore_modified_sections calls >>> VirtualProtect, another area has somehow been converted to XRW, >>> presumably by a copy-on-write event: >>> >>> 706c1000 706cd000 c000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READWRITE >>> 706cd000 706ce000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_WRITECOPY >>> 706ce000 706d3000 5000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READWRITE >>> 706d3000 706d4000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_WRITECOPY >>> >>> Finally, after VirtualProtect is called at 706C1000 by >>> restore_modified_sections, we have mostly XR but some undesirable >>> leftover X/COW and XRW pages: >>> >>> 706c1000 706cd000 c000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ >>> 706cd000 706ce000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_WRITECOPY >>> 706ce000 706d3000 5000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READWRITE >>> 706d3000 706d4000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_WRITECOPY >>> >>> Why do we have these leftovers? The function restore_modified_sections >>> is calling VirtualQuery to decide what region of memory to call >>> VirtualProtect on. Unfortunately, VirtualQuery's behavior is not quite >>> ideal for this situation: >>> >>> "The function [VirtualQuery] determines the attributes of the first >>> page in the region and then scans subsequent pages until it scans the >>> entire range of pages or until it encounters a page with a nonmatching >>> set of attributes. The function returns the attributes and the size of >>> the region of pages with matching attributes, in bytes." (From >>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366902(v=vs.85).aspx) >>> >>> So, because, after mark_section_writable, we have a mixture of XRW and >>> X/COW pages, then in restore_modified_sections, VirtualQuery is given >>> a truncated region that corresponds to only the first stretch of XRW >>> pages, terminating at the first X/COW page. And >>> restore_modified_sections only applies VirtualProtect to the truncated >>> region, leaving some XRW and X/COW pages unrestored. >>> >>> Therefore my patch changes the behavior of pseudo-reloc.c slightly. In >>> mark_section_writable, I propose storing the original bounds of the >>> region that will be VirtualProtect'd to XRW (in >>> the_secs[i].base_address and the_secs[i].region_size). Then these >>> original bounds are used by resto
Re: [Mingw-w64-public] __C_specific_handler accessible for __IA_64__ but not for __X86_64
Hello, Well, we could provide this prototype for x64 too. Not sure why we are not doing this already. Regards, Kai 2017-06-16 16:14 GMT+02:00 : > Hello, > > I'm trying to compile Gcc-7.0.1 and mingw-w64-5.0.2 in 64bits, using MSYS. > > I would like to enable the libsanitizer support, but one of the windows > depentant files complains about unknown __C_specific_handler. > > Having a look for this function, i found it in the expct.h header, but > surrounded like this : > > #if (defined(_X86_) && !defined(__x86_64)) > struct _EXCEPTION_RECORD; > struct _CONTEXT; > > EXCEPTION_DISPOSITION __cdecl _except_handler(struct _EXCEPTION_RECORD > *_ExceptionRecord, > void > *_EstablisherFrame,struct _CONTEXT *_ContextRecord, > void *_DispatcherContext); > #elif defined(__ia64__) > > typedef struct _EXCEPTION_POINTERS *Exception_info_ptr; > struct _EXCEPTION_RECORD; > struct _CONTEXT; > struct _DISPATCHER_CONTEXT; > > __MINGW_EXTENSION _CRTIMP EXCEPTION_DISPOSITION __cdecl > __C_specific_handler (struct _EXCEPTION_RECORD *_ExceptionRecord, > > unsigned __int64 _MemoryStackFp,unsigned __int64 _BackingStoreFp, > > struct _CONTEXT *_ContextRecord,struct _DISPATCHER_CONTEXT > *_DispatcherContext, > > unsigned __int64 _GlobalPointer); > #elif defined(__x86_64) > > struct _EXCEPTION_RECORD; > struct _CONTEXT; > #endif > > (end of line are mine) > > Is there any reason to make this extension aviable for IA_64 only or could > we considere to make it aviable for X86_64 too? > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?
2017-06-22 18:41 GMT+02:00 Lev Serebryakov :
> On 22.06.2017 16:17, Kai Tietz via Mingw-w64-public wrote:
>
>> Be welcome. Well, actually gcc has one paragraph about this. You can
>> find it in gcc's extend.texi. It is part of the item 'format
>> (@var{archetype}, ...' about attributes.
> I've looked at GCC online documentation :) It mention ms_* but not
> gnu_* for mingw target.
>
> One more question: looks like PRId64 and others from are
> always "I64", am I right? Is it possible to get ISO-standard defines for
> int64_t/uint64_t?
You should take another look. We actually do this. See our internal
headers _mingw_print_pop.h and _mingw_print_push.h for this magic
> I've checked and both _POSIX_C_SOURCE=1 and __USE_MINGW_ANSI_STDIO=1
> don't affect this define.
It should, at least the latter one should show effect. Of course you
need to define it before including inttypes.h
> --
> // Black Lion AKA Lev Serebryakov
Regards,
Kai
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Added oleacc.tlb.
Hello Jacek, patch is ok. Thanks, Kai 2017-06-19 18:16 GMT+02:00 Jacek Caban : > Please review. > > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/Makefile.am| 1 + > mingw-w64-headers/tlb/oleacc.idl | 382 > +++ > 2 files changed, 383 insertions(+) > create mode 100644 mingw-w64-headers/tlb/oleacc.idl > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?
2017-06-22 14:19 GMT+02:00 Lev Serebryakov :
> On 22.06.2017 15:12, Kai Tietz via Mingw-w64-public wrote:
>
>> Well, your issue is "(format (printf, ... )". First use __printf, or
>> even better __printf__. Nevertheless the printf formatter is
>> representing the default print-formatter style. That is obviously on
>> Windows not the gnu-ish variant.
>>
>> But you can explicit tell it, that you want to use a different
>> variant. Eg "__attribute__((__format__ (gnu_printf,..." for gnu-style.
> Oh, thank you! It is not obvious, as it is not mentioned in GCC
> documentation :)
>
> --
> // Black Lion AKA Lev Serebryakov
Be welcome. Well, actually gcc has one paragraph about this. You can
find it in gcc's extend.texi. It is part of the item 'format
(@var{archetype}, ...' about attributes.
Cheers,
Kai
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] strsafe.h: Added missing _STRSAFE_EXTERN_C in cases when inlining is disables.
2017-06-20 3:52 GMT+02:00 Liu Hao : > On 2017/6/20 1:40, Jacek Caban wrote: >> >> Please review. >> >> Signed-off-by: Jacek Caban >> --- >> mingw-w64-headers/include/strsafe.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> > We might have to test this patch with different `-std=` options with > different optimization levels because of different behavior of `extern > inline` in C89, C99 and C++. > > -- > Best regards, > LH_Mouse Sure, but patch of Jacek just touches the none-inline variant, isn't it? So IMHO patch is ok. Regards, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?
2017-06-22 13:39 GMT+02:00 Lev Serebryakov :
> Hello Liu,
>
> Thursday, June 22, 2017, 4:46:33 AM, you wrote:
>
So, I need to printf() uint64_t in my project, which is built in strict
ISO C11 mode and with all warnings enabled.
>>>
If I try to use "%llu" I get warning that "unknown conversion type
character 'l' in format". If I use "%I64u" I get "ISO C does not support
the 'I64' ms_printf length modifier" warning.
>>> And, yes, I have _POSIX_C_SOURCE defined on compiler's command line.
>>>
>> In order to get C99 conforming `*printf()` functions you have to
>> `#define __USE_MINGW_ANSI_STDIO 1` before inclusion of any standard
>> headers. One preferable way to achieve that is adding
>> `-D__USE_MINGW_ANSI_STDIO` into your CPPFLAGS.
> I've started to prepare minimal example for my problem and found one more
> ingridient for my problem:" custom function with prinrf attribute. These
> defines work for system *printf() family, but not for custom ones.
>
> Here is very simple example of exactly my problem:
>
> ==
> #include
> #include
> #include
>
> __attribute__ ((format (printf, 1, 2)))
> void myprintf(const char *fmt, ...) {
> va_list args;
> va_start(args, fmt);
> vprintf(fmt, args);
> va_end(args);
> }
>
> int main(int argc, char *argv[]) {
> uint64_t i = 10;
> size_t s = 20;
> (void)argc; (void)argv;
> printf("%llu %zu\n", i, s);
> myprintf("%llu %zu\n", i, s);
> return 0;
> }
> ==
> lev@lion MINGW64 ~
> $ gcc -D_POSIX_C_SOURCE=1 test.c
>
> lev@lion MINGW64 ~
> $ ./a.exe
> 10 20
> 10 20
>
> lev@lion MINGW64 ~
> $ gcc -D_POSIX_C_SOURCE=1 -std=c11 -Wall -Wextra -Wpedantic -Wformat=2
> -Werror test.c
> test.c: In function 'main':
> test.c:17:15: error: unknown conversion type character 'l' in format
> [-Werror=format=]
>myprintf("%llu %zu\n", i, s);
>^
> test.c:17:19: error: unknown conversion type character 'z' in format
> [-Werror=format=]
>myprintf("%llu %zu\n", i, s);
>^
> test.c:17:12: error: too many arguments for format [-Werror=format-extra-args]
>myprintf("%llu %zu\n", i, s);
> ^~~~
> cc1.exe: all warnings being treated as errors
>
> lev@lion MINGW64 ~
> $
>
>
>
>
> --
> Best regards,
> Levmailto:l...@serebryakov.spb.ru
Well, your issue is "(format (printf, ... )". First use __printf, or
even better __printf__. Nevertheless the printf formatter is
representing the default print-formatter style. That is obviously on
Windows not the gnu-ish variant.
But you can explicit tell it, that you want to use a different
variant. Eg "__attribute__((__format__ (gnu_printf,..." for gnu-style.
We define for this the helper macros __MINGW_PRINTF_FORMAT, and
__MINGW_SCANF_FORMAT depending on __USE_MINGW_ANSI_STDIO's macro
definition.
By this, you can use instead
__attribute__((__format__(__MINGW_PRINTF_FORMAT, ".
Hope this helps.
Cheers,
Kai
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?
2017-06-22 4:53 GMT+02:00 : > -Original Message- From: Liu Hao > Sent: Thursday, June 22, 2017 11:46 AM > To: mingw-w64-public@lists.sourceforge.net > Subject: Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit > compiler in strict ISO mode with all warnings enabled? > >>> So, I need to printf() uint64_t in my project, which is built in strict >>> ISO C11 mode and with all warnings enabled. >>> >>> If I try to use "%llu" I get warning that "unknown conversion type >>> character 'l' in format". If I use "%I64u" I get "ISO C does not support >>> the 'I64' ms_printf length modifier" warning. >>> And, yes, I have _POSIX_C_SOURCE defined on compiler's command line. >> >> >> In order to get C99 conforming `*printf()` functions you have to `#define >> __USE_MINGW_ANSI_STDIO 1` before inclusion of any standard headers. One >> preferable way to achieve that is adding `-D__USE_MINGW_ANSI_STDIO` into >> your CPPFLAGS. > > > This is what I invariably do, too. > > However, in a recent post to a gmp mailing list ( > https://gmplib.org/list-archives/gmp-bugs/2017-May/004162.html ), Keith > Marshall discouraged this, warning that it was *not* guaranteed to continue > to work into the future. > > Here's the relevant bit (from that post) of what he had to say: > > [--quote--] > > I would also point out that, as a "__USE_*" feature test, users should *not* > define "__USE_MINGW_ANSI_STDIO" themselves; the correct way to enable it is > to enable any of the "__STRICT_ANSI__" standards options, or to stipulate > "_GNU_SOURCE", "_POSIX_C_SOURCE", or "_XOPEN_SOURCE" feature dependencies, > (the latter two with an associated version stipulation), any of which will > cause the MinGW runtime headers to enable "__USE_MINGW_ANSI_STDIO" > implicitly. You may get away with an explicit definition today, but I will > offer no guarantee that a future MinGW Runtime release will not override any > such definition, just as GNU's glibc headers do for their "__USE_*" feature > tests. > > [--end quote--] > > AFAIK Keith's allegiance is with mpfr.org, and I don't know how/if those > remarks relate to mingw-w64. Well, we don't intend to remove our gnu-ish printf/scanf implementation (C99) in near, or mid-term distance. I agree that this feature needs to be used carefully, as it modifies common Windows API expectations. I don't see why this gnu-style-formatter routines are should be bould to POSIX. But I admit, it is a work-a-round for a portability issue. As it is a C99 feature, STRICT_ANSI looks to me wrong too. For _GNU_SOURCE we could consider that too. > Any thoughts on that ? > > Cheers, > Rob Regards, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?
I agree that - if we want to increase default windows version - we should bump our default to Windows 7. Windows Vista is already on the way to die ... Nevertheless, IMHO we should do that increase just for our master. Regards, Kai 2017-06-04 1:33 GMT+02:00 Martell Malone : > Thanks for that clarification Ricardo. > It seems that when we bumped we didn't bump far enough :) > Kai what are your thoughts? > > On Sun, Jun 4, 2017 at 12:13 AM, Ricardo Constantino > wrote: > >> On 3 June 2017 at 19:52, Mateusz Mikuła wrote: >> >> > 0x0502 is Windows Server 2003 >> > >> > If changing default target it should be done properly. Windows Vista is >> > EOL and it's share is lower than XP so I'd vote for Windows 7. >> > >> > >> > -- Original Message -- >> > Subject: [Mingw-w64-public] Default _WIN32_WINNT version too low? >> > Date: Sat, 3 Jun 2017 18:27:40 +0100 >> > To: Mingw-w64-public >> > From: Martell Malone >> > > Hey, >> > > >> > > As per my discussion with LLVM devs here. >> > > 0x600 is the min version required to support libc++ win32 threading. >> > > https://reviews.llvm.org/D33384 >> > > >> > > I'm not quite sure why we currently have 0x502 as the default. >> > > It seems to be a number sitting between Windows XP and Vista. >> > >> >> Besides being Windows Server 2003 it's also XP SP2. >> >> >> > > I would like to propose we bump to 0x600 which is Vista for this >> reason. >> > > >> > > Kind Regards >> > > Martell >> > > >> > -- >> > > Check out the vibrant tech community on one of the world's most >> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > > ___ >> > > Mingw-w64-public mailing list >> > > Mingw-w64-public@lists.sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > >> > >> > >> > -- >> > Check out the vibrant tech community on one of the world's most >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > ___ >> > Mingw-w64-public mailing list >> > Mingw-w64-public@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > >> > >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l
Well,
the inline variant seems fine to me. I would prefer to have here
instead an implementation file. As later allows us to provide such a
function from import-library too.
Cheers,
Kai
2017-06-04 2:10 GMT+02:00 Martell Malone :
> Following up with an initial patch
> Not sure if this is ideal because this will be used over the MSVC version.
> I can add it to a c source as an emulation if that suits better
>
> diff --git a/mingw-w64-headers/crt/time.h b/mingw-w64-headers/crt/time.h
> index 7f5bbb78..405a9f1d 100644
> --- a/mingw-w64-headers/crt/time.h
> +++ b/mingw-w64-headers/crt/time.h
> @@ -129,7 +129,9 @@ extern "C" {
>struct tm *__cdecl _localtime32(const __time32_t *_Time)
> __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
>_SECIMP errno_t __cdecl _localtime32_s (struct tm *_Tm,const __time32_t
> *_Time);
>size_t __cdecl strftime(char * __restrict__ _Buf,size_t
> _SizeInBytes,const char * __restrict__ _Format,const struct tm *
> __restrict__ _Tm);
> - _CRTIMP size_t __cdecl _strftime_l(char * __restrict__ _Buf,size_t
> _Max_size,const char * __restrict__ _Format,const struct tm * __restrict__
> _Tm,_locale_t _Locale);
> + __forceinline size_t __cdecl _strftime_l(char * __restrict__ _Buf,size_t
> _Max_size,const char * __restrict__ _Format,const struct tm * __restrict__
> _Tm,_locale_t _Locale) {
> +return strftime(_Buf, _Max_size, _Format, _Tm);
> + }
>_CRTIMP char *__cdecl _strdate(char *_Buffer)
> __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
>_SECIMP errno_t __cdecl _strdate_s (char *_Buf,size_t _SizeInBytes);
>_CRTIMP char *__cdecl _strtime(char *_Buffer)
> __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
>
> On Mon, May 22, 2017 at 12:18 PM, Martell Malone
> wrote:
>
>> Thanks for spotting that strangely MSDN seems to think it does exist.
>> https://docs.microsoft.com/en-gb/cpp/c-runtime-library/
>> reference/strftime-wcsftime-strftime-l-wcsftime-l
>> I have no problem in doing an emulation for "strftime_l".
>> I would rather not use random msvcrt versions :)
>>
>> On Mon, May 22, 2017 at 12:14 PM, Liu Hao wrote:
>>
>>> On 2017/5/22 18:43, JonY wrote:
>>> > On 05/22/2017 07:57 AM, Liu Hao wrote:
>>> >> On 2017/5/22 2:05, Martell Malone wrote:
>>> >>> Context: libc++ uses strftime_l now
>>> >>>
>>> >>> Please Review
>>> >> The DEF files are generated from DLLs. I don't have Win10 at hand so I
>>> >> have asked jon_y on IRC to update them.
>>> >>
>>> >
>>> > Win10 msvcrt doesn't have strftime_l, checked on 1607.
>>> Thanks for confirmation.
>>>
>>> On my Windows 7 the function `_strftime_l` is available in
>>> MSVCR{80,90,100,110,120}.DLL, but is not available in MSVCR{T,70}.DLL.
>>> So the patch can't be applied here.
>>>
>>> When I took my last look at libcxx it required MSVCR90 to build. I am
>>> not sure which version of MSVCR* libcxx requires today but I am afraid
>>> it can't be built with only MSVCRT. That is, in order to build libcxx
>>> you have to *replace* the default `-lmsvcrt` with `-lmsvcr90` (MSVCR90
>>> is fragile so I suggest you use `-lmsvcr100`). In the case of GCC this
>>> can be done by dumping GCC's default specs file, modifying it, then
>>> building use the modified specs.
>>>
>>> --
>>> Best regards,
>>> LH_Mouse
>>>
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Semi-OT: Is this sourceforge email legit? (Fwd: Important Account Information - Reconfirm Mailing List Subscriptions)
Hello, yes, everybody seems to get such a mail for the subscribed sf public mailing lists. SF changed describes the reasoning at https://sourceforge.net/blog/sourceforge-project-e-mail-policy-update/ for further information. Regards, Kai 2017-06-09 7:26 GMT+02:00 LRN : > On 6/9/2017 6:13 AM, K. Frank wrote: >> Hello List! >> >> I just wanted to check whether this email from sourceforge is legit. >> It seemed a little odd -- out of the blue -- and sourceforge has earned >> itself an imperfect reputation. >> >> Is this okay? Have others got this? >> >> >> -- Forwarded message -- >> From: SourceForge.net >> Date: Thu, Jun 8, 2017 at 6:34 PM >> Subject: Important Account Information - Reconfirm Mailing List Subscriptions >> To: > > The message does mention reconfirmation via sourceforge.net website. So if > you, > like me, mistrust the email, just log into your SF.net account and reconfirm > there. > > > -- > O< ascii ribbon - stop html email! - www.asciiribbon.org > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] static lib/Visual Studio problem
Mixing C++ from different compilers is one of the ultimate adventurous roads to go. Nevertheless you can still share C API instead. Anyway, if you want to use mingw-w64 together with VS, I would recomment to switch to Clang for mingw-w64 (llvm). It is capable to produce mostly compatible C++ code for VS. This might be a solution for your issue. Regards, Kai 2017-06-07 5:07 GMT+02:00 Brad Garton : > On Tue, Jun 6, 2017 at 8:30 PM, David Grayson > wrote: > >> >> Why do you want to build your application using both Visual Studio and >> MinGW? Why not pick one and stick with it? > > > It's the unix heritage. It's much easier to get it to compile with mingw, > but it looks like I'll have to go with building it entirely in VS. > > brad > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] sal.h: Disable __in and __out macros when using libstdc++.
Jacek, thanks for fixing this. Please go ahead, and apply. Cheers, Kai 2017-05-29 22:01 GMT+02:00 Jacek Caban : > Hi David, > > > Good catch, thanks. I sent a fixed version. > > > Jacek > > > > On 5/29/17 9:56 PM, David Grayson wrote: >> >> The boolean logic in the patch looks wrong to me. You're going to end >> up disabling __in and __out for all GCC and Clang programs regardless >> of what language they use because __GNUC__ will be defined. >> >> Seems like this would be better: >> >> #if defined(__cplusplus) && defined(__GNUC__) >> // Don't define __in and __out because they conflict with libstdc++. >> #else >> #define __in >> #define __out >> #endif >> >> --David >> >> >> >> On Mon, May 29, 2017 at 12:43 PM, Jacek Caban >> wrote: >>> >>> I've seen a very good news that a fix to libstdc++ is on its way and >>> that's >>> great. However, we need to support already released versions as well. >>> That's >>> why I propose this patch. Ideally, we'd use __GLIBCXX__ macro, but it's >>> not >>> available without including any standard header and sal.h is not a good >>> place to do that. In the future, when libstdc++ is fixed, we may change >>> guards to be version-dependent. >>> >>> Signed-off-by: Jacek Caban >>> --- >>> mingw-w64-headers/include/sal.h | 8 +++- >>> 1 file changed, 7 insertions(+), 1 deletion(-) >>> >>> >>> >>> >>> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> ___ >>> Mingw-w64-public mailing list >>> Mingw-w64-public@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
2017-05-17 16:25 GMT+02:00 David Grayson : > On Wed, May 17, 2017 at 4:10 AM, Kai Tietz wrote: >> The best solution would be something like to include >> driverspecs.h in specstring.h only, if user intends to use ddk. > > Is that how the real DDK works? When you don't have the DDK > installed, you can still include specstrings.h but it somehow does not > include driverspecs.h? > > --David Grayson No idea, and nothing of much interest to us AFAICS. For us, ddk is an optional component. It isn't mandatory to include it at all. It is controlled by an configure option to our header's build. That means, to rely on driverspecs.h seems to be the wrong thing. Including it on purpose, if user wants it, sounds something fair. But to enforce dependency to it in general feels wrong. Cheers, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
2017-05-17 16:10 GMT+02:00 David Grayson :
> Here's the sed command again, without bad line wrapping:
>
> https://gist.github.com/DavidEGrayson/ee9796a900eedda3d6b7c8f2324793a4
>
> --David
This sed command is nice, but nothing to be recommended for our users.
Driver buiding is for sure the more rare case, and most users won't be
interested in that pretty much. For those which are, this might be a
way.
Once again, why we include by default driverspecs.h ? Is that of any
meaning, beside for people using ddk?
> On Wed, May 17, 2017 at 7:08 AM, David Grayson
> wrote:
>> A GCC maintainer has spoken up and said they will accept a patch to
>> rename __in and __out to other things:
>>
>> https://gcc.gnu.org/ml/gcc-help/2017-05/msg00152.html
Sure, saw that, but this is not the point. See above.
>> As soon as I have a bit of free time, I will submit such a patch to
>> them, though LH_Mouse might beat me to it.
>>
>> So in the long term, we can have __in and __out, and we can have
>> compatibility with libstdc++v3. I'd rather not change mingw-w64.
Iff libstdc++ will be modified, then we can enable these include with
a gcc version check. But it is nothing mandatory to use up to date
gcc version, so again, this is a pie in the sky, nothing else.
>> In the MSYS2 project, we've already dealt with this issue by
>> generating a patch for libstdc++v3 using this command I put together:
What msys2 hacks, is in msys2's responsibility. On mingw-w64 we can't
do such things, as we have to deal with a much wider user range, and
not just for one environment.
>> sed -ri 's/\b(__in|__out)\b/_&/g' $(egrep -rl '\b(__in|__out)\b'
>> libstdc++-v3/{include,config})
>>
>> If you are compiling your own mingw-w64 toolchain, you should be
>> capable of just running that line of code before building GCC to fix
>> the name collision.
>>
>> If you are a user who is using a broken mingw-w64 toolchain, you
>> should tell the people who built it about the line above, but in the
>> meantime, you can edit driverspecs.h with a text editor and uncomment
>> the lines that define __in and __out.
>>
>> So I think the status quo is totally fine.
>>
>> But if we do change mingw-w64, I can revert your change in my builds,
>> and that works too, and it's just as easy as getting other toolchain
>> builders to run the sed command. If we do change mingw-w64, what
>> would be the timeline for reverting that change? Would we wait until
>> the offending versions of libstdc++ have been replaced by fixed stable
>> for versions for, say, 5 years?
>>
>> --David Grayson
>>
>> On Wed, May 17, 2017 at 6:18 AM, Mateusz wrote:
>>> W dniu 2017-05-17 o 13:10, Kai Tietz pisze:
>>>> Hello,
>>>>
>>>> I dislike such a change. As if somebody wants to driverspec.h, op
>>>> will need these symbols defined. Otherwise build will badly fail.
>>>> So this brings us back to the reasoning of this ... adding to
>>>> specstrings.h the include of driverspecs.h. IMHO this shouldn't be
>>>> done always. The best solution would be something like to include
>>>> driverspecs.h in specstring.h only, if user intends to use ddk.
>>>> Otherwise we shouldn't include this header at all.
>>>>
>>>> Any thoughts?
>>>>
>>>> Regards,
>>>> Kai
>>>
>>> We could roll back commit [b7f44b].
>>>
>>> Now there are new commits and this should be fixed.
>>>
>>> Mateusz
>>>
>>>
>>>
>>>>
>>>>
>>>> 2017-05-17 12:34 GMT+02:00 Mateusz :
>>>>> We really should do something with '__in' and '__out' from driverspecs.h.
>>>>>
>>>>> Please review.
>>>>>
>>>>>
>>>>> --
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> ___
>>>>> Mingw-w64-public mailing list
>>>>> Mingw-w64-public@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>>>
>>>>
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engag
Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++
Hello, I dislike such a change. As if somebody wants to driverspec.h, op will need these symbols defined. Otherwise build will badly fail. So this brings us back to the reasoning of this ... adding to specstrings.h the include of driverspecs.h. IMHO this shouldn't be done always. The best solution would be something like to include driverspecs.h in specstring.h only, if user intends to use ddk. Otherwise we shouldn't include this header at all. Any thoughts? Regards, Kai 2017-05-17 12:34 GMT+02:00 Mateusz : > We really should do something with '__in' and '__out' from driverspecs.h. > > Please review. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
I would prefer this too, but I don't believe that we can convince
libstdc++ maintainers to modify their code for this. Sadly the MS'
platform sdk defines a lot of stuff, which collides some times with
some projects. We made about this already a lot of bad experiences
... especially in context of MIDL ... defining
IN/OUT/INOUT/OPTIONAL/etc is really no clever move ...
Nevertheless it might be worth a try to ask libstdc++ people for those
__in A good argument (and bad one too) might be that the double
underscore symbols are reserved to compilers/system headers. And
well, C++ headers aren't really system headers, which is in general
just a POV ;)
Regards,
Kai
2017-05-11 16:32 GMT+02:00 David Grayson :
> Oh, I thought we should just get libstdc++ to patch their project. I would
> look for __in and any other badly-named parameters, and perhaps add a third
> underscore to their names or something like that. In the long term, that
> would be nicer, because then users can have Microsoft-style code and
> libstdc++ code used in the same translation unit and they don't have to
> remember to use a guard on the include.
>
> --David
>
> On Thu, May 11, 2017 at 7:24 AM, Kai Tietz wrote:
>
>> Yes, that is a bit annoying ... sadly we can't do much about it.
>>
>> So I would suggest to add a guard to the include, so that it is
>> user-defined, if this header should be included, or not.
>> This might be a work-a-round for this, which should work for most.
>>
>> Regards,
>> Kai
>>
>> 2017-05-11 15:51 GMT+02:00 David Grayson :
>> > Unfortunately, my patch seems to break several classes in libstdc++,
>> > preventing Qt from building. The problem is that driverspecs.h defines
>> > __in to be empty so we can compile Microsoft-type code that uses __in as
>> a
>> > source annotation on function parameters while GCC's libstdc++ uses __in
>> as
>> > the name of an input argument for many of its methods:
>> >
>> > $ egrep -lr '\b__in\b' /mingw32/include/
>> > /mingw32/include/c++/6.3.0/bits/basic_string.h
>> > /mingw32/include/c++/6.3.0/bits/basic_string.tcc
>> > /mingw32/include/c++/6.3.0/bits/istream.tcc
>> > /mingw32/include/c++/6.3.0/bits/locale_facets.h
>> > /mingw32/include/c++/6.3.0/ext/random.tcc
>> > /mingw32/include/c++/6.3.0/ext/vstring.tcc
>> > /mingw32/include/c++/6.3.0/istream
>> > /mingw32/include/c++/6.3.0/tr1/tuple
>> > /mingw32/include/c++/6.3.0/tr1/utility
>> > /mingw32/include/c++/6.3.0/tr2/bool_set
>> > /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
>> > /mingw32/include/c++/6.3.0/tuple
>> > /mingw32/include/c++/6.3.0/utility
>> >
>> > One of the errors I get looks like this:
>> >
>> > /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function
>> for
>> > call to 'move()'
>> > { return __pair_get<_Int>::__move_get(std::move(__in)); }
>> >
>> > I don't think this is necessarily a problem with mingw-w64, or a problem
>> > with that patch. Adrien Nader's attitude on this mailing list in
>> > 2015-11-03 was "Really, there's a platform and software is built on top
>> of
>> > it; it is that software that is supposed to adapt to the platform."
>> Microsoft
>> > Windows and mingw-w64 are platforms that define __in to have a special
>> > meaning. The software built on that platform (libstdc++) should adapt to
>> > the platform.
>> >
>> > One odd thing is that our __in gets defined in driverspecs.h, while
>> > Microsoft defines their __in in sal.h. But specstrings.h (for both
>> > mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
>> > shouldn't affect when the bug appears.
>> >
>> > --David Grayson
>> >
>> > On Wed, May 10, 2017 at 9:44 AM, David Grayson
>> > wrote:
>> >
>> >> Yeah, sorry, I only sent those patches to LH by mistake. Yes, I
>> purposely
>> >> used the same include guard name as Microsoft.
>> >>
>> >> --David
>> >>
>> >> On Wed, May 10, 2017 at 8:55 AM, Liu Hao wrote:
>> >>
>> >>>
>> >>>
>> >>>
>> >>> Forwarded Message
>> >>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>> >>> specstrings.h.
>> >>> Date: Wed, 10 May 2017 08:24:25 -0700
>> >>> From: David Grayson
>> >>> To: Liu H
Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.
Yes, that is a bit annoying ... sadly we can't do much about it.
So I would suggest to add a guard to the include, so that it is
user-defined, if this header should be included, or not.
This might be a work-a-round for this, which should work for most.
Regards,
Kai
2017-05-11 15:51 GMT+02:00 David Grayson :
> Unfortunately, my patch seems to break several classes in libstdc++,
> preventing Qt from building. The problem is that driverspecs.h defines
> __in to be empty so we can compile Microsoft-type code that uses __in as a
> source annotation on function parameters while GCC's libstdc++ uses __in as
> the name of an input argument for many of its methods:
>
> $ egrep -lr '\b__in\b' /mingw32/include/
> /mingw32/include/c++/6.3.0/bits/basic_string.h
> /mingw32/include/c++/6.3.0/bits/basic_string.tcc
> /mingw32/include/c++/6.3.0/bits/istream.tcc
> /mingw32/include/c++/6.3.0/bits/locale_facets.h
> /mingw32/include/c++/6.3.0/ext/random.tcc
> /mingw32/include/c++/6.3.0/ext/vstring.tcc
> /mingw32/include/c++/6.3.0/istream
> /mingw32/include/c++/6.3.0/tr1/tuple
> /mingw32/include/c++/6.3.0/tr1/utility
> /mingw32/include/c++/6.3.0/tr2/bool_set
> /mingw32/include/c++/6.3.0/tr2/bool_set.tcc
> /mingw32/include/c++/6.3.0/tuple
> /mingw32/include/c++/6.3.0/utility
>
> One of the errors I get looks like this:
>
> /nix/.../include/c++/6.3.0/utility:208:57: error: no matching function for
> call to 'move()'
> { return __pair_get<_Int>::__move_get(std::move(__in)); }
>
> I don't think this is necessarily a problem with mingw-w64, or a problem
> with that patch. Adrien Nader's attitude on this mailing list in
> 2015-11-03 was "Really, there's a platform and software is built on top of
> it; it is that software that is supposed to adapt to the platform." Microsoft
> Windows and mingw-w64 are platforms that define __in to have a special
> meaning. The software built on that platform (libstdc++) should adapt to
> the platform.
>
> One odd thing is that our __in gets defined in driverspecs.h, while
> Microsoft defines their __in in sal.h. But specstrings.h (for both
> mingw-w64 and Microsoft) includes both sal.h and driverspecs.h so that
> shouldn't affect when the bug appears.
>
> --David Grayson
>
> On Wed, May 10, 2017 at 9:44 AM, David Grayson
> wrote:
>
>> Yeah, sorry, I only sent those patches to LH by mistake. Yes, I purposely
>> used the same include guard name as Microsoft.
>>
>> --David
>>
>> On Wed, May 10, 2017 at 8:55 AM, Liu Hao wrote:
>>
>>>
>>>
>>>
>>> Forwarded Message
>>> Subject:Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in
>>> specstrings.h.
>>> Date: Wed, 10 May 2017 08:24:25 -0700
>>> From: David Grayson
>>> To: Liu Hao
>>>
>>>
>>>
>>> OK, thanks. I've attached a new patch where the #include is after the
>>> __cplusplus stuff.
>>>
>>> I also included a second patch that will add an include guard for
>>> specstrings.h, since Microsoft seems to do that too.
>>>
>>> driverspecs.h is also missing an include guard but it is part of the
>>> React DDK so I didn't want to mess around with editing at the moment.
>>>
>>> --David
>>>
>>> On Tue, May 9, 2017 at 9:07 PM, Liu Hao >> lh_mo...@126.com>> wrote:
>>>
>>> On 2017/5/10 10:34, David Grayson wrote:
>>>
>>> This patch adds "#include " near the end of
>>> specstrings.h,
>>> because the same is done in Microsoft's version of
>>> specstrings.h. With
>>> this patch, I am able to build Microsoft's devcon utility without
>>> modification. Thanks!
>>>
>>> You must `#include` that header AFTER the `#ifdef __cplusplus ...
>>> #endif` block.
>>>
>>> Anyway, this header seems short of a header guard. I shall ask
>>> someone for sure.
>>>
>>> -- Best regards,
>>> LH_Mouse
>>>
>>>
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>>
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.ne
Re: [Mingw-w64-public] [PATCH] intrincs: check for __rdtsc
Hmm, where is the corresponding pop_macro pragma?
Regards,
Kai
2017-05-11 14:09 GMT+02:00 Martell Malone :
>>
>> While it's not "good form" to have the prototype
>> in multiple places...
>
> Attached updated diff
>
> Please Review
>
> diff --git a/mingw-w64-crt/intrincs/rdtsc.c b/mingw-w64-crt/intrincs/rdtsc.c
> index fd9cb75d..7c5adeb0 100644
> --- a/mingw-w64-crt/intrincs/rdtsc.c
> +++ b/mingw-w64-crt/intrincs/rdtsc.c
> @@ -4,11 +4,15 @@
> * No warranty is given; refer to the file DISCLAIMER.PD within this
> package.
> */
> -#ifdef __clang__
> -#define __IA32INTRIN_H
> -#endif
> #include
> +/* Clang has support for MSVC builtins, GCC doesn't */
> +#pragma push_macro("__has_builtin")
> +#ifndef __has_builtin
> + #define __has_builtin(x) 0
> +#endif
> +
> +#if !__has_builtin(__rdtsc)
> unsigned __int64 __rdtsc(void)
> {
> #ifdef _WIN64
> @@ -21,4 +25,4 @@ unsigned __int64 __rdtsc(void)
>: "=a" (val1), "=d" (val2));
>return ((unsigned __int64)val1) | (((unsigned __int64)val2) << 32);
> }
> -
> +#endif
>
> On Sun, Apr 16, 2017 at 3:06 AM, David Wohlferd
> wrote:
>
>> On 4/14/2017 7:14 AM, Martell Malone wrote:
>> > Updated clang no longer defines __IA32INTRIN_H so lets do this properly.
>>
>> It appears that the only use for in that file is the
>> prototype for __rdtsc. While it's not "good form" to have the prototype
>> in multiple places...
>>
>> > I assume intrin-impl.h is only ever included by intrin.h?
>>
>> Fraid not.
>>
>> mingw-w64-headers\include\winbase.h:#include
>> mingw-w64-headers\include\winnt.h:#include
>>
>> > If not I will have to find a way to deal with __has_builtin in both files
>>
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.
ok, please apply.
Thanks,
Kai
2017-05-08 12:19 GMT+02:00 Liu Hao :
> On 2017/5/3 15:35, Christer Solskogen wrote:
>>
>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>> with gcc 7.1.
>> (... abridgement ...)
>> src/.libs/libwinpthread_la-clock.o:clock.c:(.text+0x270): undefined
>> reference to `__divmoddi4'
>
> Here is the 'real' fix for it. Please review.
>
> (I really hate this C-ish code but this way it looks like how `__udivdi3`
> was implemented.)
>
> --
> Best regards,
> LH_Mouse
>
>
>
>
> From 04f0579cb7e2f294e1e3ad2be18b8d059546208f Mon Sep 17 00:00:00 2001
> From: Liu Hao
> Date: Wed, 3 May 2017 15:52:32 +0800
> Subject: [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for
> GCC
> 7.
>
> GCC targeting i686 _may_ generate an external call to the function in
> question when divding a 64-bit (DIMode) integer with another one.
> Since we are linking against a fake libgcc, this function is not available.
>
> Signed-off-by: Liu Hao
> ---
> .../winpthreads/src/libgcc/dll_math.c | 27
> ++
> 1 file changed, 27 insertions(+)
>
> diff --git a/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
> b/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
> index e09b481b..aeec0680 100644
> --- a/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
> +++ b/mingw-w64-libraries/winpthreads/src/libgcc/dll_math.c
> @@ -120,6 +120,7 @@ u_quad_t__qdivrem(u_quad_t u, u_quad_t v, u_quad_t
> *rem);
> u_quad_t __udivdi3(u_quad_t a, u_quad_t b);
> u_quad_t __umoddi3(u_quad_t a, u_quad_t b);
> int__ucmpdi2(u_quad_t a, u_quad_t b);
> +quad_t __divmoddi4(quad_t a, quad_t b, quad_t *rem);
>
> #endif /* !_LIBKERN_QUAD_H_ */
>
> @@ -546,6 +547,32 @@ __umoddi3(a, b)
> (void)__qdivrem(a, b, &r);
> return (r);
> }
> +
> +/*
> + * Divide two signed quads.
> + * This function is new in GCC 7.
> + */
> +quad_t
> +__divmoddi4(a, b, rem)
> + quad_t a, b, *rem;
> +{
> + u_quad_t ua, ub, uq, ur;
> + int negq, negr;
> +
> + if (a < 0)
> + ua = -(u_quad_t)a, negq = 1, negr = 1;
> + else
> + ua = a, negq = 0, negr = 0;
> + if (b < 0)
> + ub = -(u_quad_t)b, negq ^= 1;
> + else
> + ub = b;
> + uq = __qdivrem(ua, ub, &ur);
> + if (rem)
> + *rem = (negr ? -ur : ur);
> + return (negq ? -uq : uq);
> +}
> +
> #else
> static int __attribute__((unused)) dummy;
> #endif /*deined (_X86_) && !defined (__x86_64__)*/
> --
> 2.12.1
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.
I think, it is worth a try. In general it looks sensible. Kai 2017-05-02 11:56 GMT+02:00 Liu Hao : > Kai, did you mean this patch was ok for master? > > -- > Best regards, > LH_Mouse > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c
Ok, thanks for trying to get the reasoning, why we didn't marked it as selectany. So I think it is time to add this selectany to our master, and see if we get really any issues reported for it. The only scenario I am concerned about is user-defined, library defined. As prototypes are changing, and it might be that gcc sees selectany to some extend as ABI-relevant and errors out. Regards, Kai 2017-05-02 7:57 GMT+02:00 Liu Hao : > On 2017/5/2 12:04, David Grayson wrote: >> Thanks for the info. >> >> I used "git blame" on guiddef.h and it looks like the logic has been the >> same since 2007. I don't see any sign that Kai removed the >> DECLSPEC_SELECTANY from the GUID declarations, as far as I know it was just >> always missing. >> >> So the code has been the same for 10 years, but then two people have >> complained about it on the mailing list in the last week. Perhaps there >> was a change in GCC that made it start ignoring certain attributes on >> variable definitions if the attributes were not present on the declaration. >> >> Tomay: are you able to apply my patch, rebuild your mingw-w64 libraries, >> and see if it fixes your issue? If you can't do that, could you tell me >> what the steps are to reproduce your issue so I can see whether the patch >> helps? >> >> Will the patch get merged if I try to reproduce the problem Kai mentioned >> about having a GUID collision and I fail to reproduce it? > Again, I am considering about removing duplicate definitions of > UUIDs/GUIDs as the 'real' resolution. But before doing that I _have to_ > understand why those duplicates have been there. > > > -- > Best regards, > LH_Mouse > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
2017-04-07 17:21 GMT+02:00 David Grayson :
>> type1 *foo(const type1 *my_const_ptr)
>> {
>> union {
>> type1 *t1;
>> const type1 *ct1;
>> } v;
>> v.ct1 = my_const_ptr;
>> return v.t1;
>> }
>
> Yes, that is sad, and it seems like just a matter of time before a C++
> compiler looks at the code above and reasons that the write to ct1 can be
> optimized away because there is no code that ever reads from ct1. Thus the
> read from t1 will be recognized as undefined behavior (probably called a
> poison value in LLVM) and anything could happen.
LOL ... if a compiler modifies a technical valid language construct,
and produces by this optimization something it needs to warn about,
then the compiler has a bug. And well, you should be sad to use such
a compiler, as it is broken in many aspects.
> What was the problem with Mateusz's patch? I think people are implying it
> results in compiler warnings, but I thought casting a pointer to a pointer
> usually doesn't give any warnings.
The problem is that you seems to see an UB, where actually none is.
Please try read a bit about C++, compatibility to C, and what, and how
a union on pointer types are treated in a union (especially the part
about integer scalars & pointers).
~Kai
PS: As you already recognized, yes the issue is to avoid warnings OP
doesn't expect them.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winnt.h: Added missing entries to WELL_KNOWN_SID_TYPE.
Patch is ok. Please apply. Thanks, Kai 2017-04-07 14:06 GMT+02:00 Jacek Caban : > Please review. > > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/winnt.h | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
2017-04-06 15:06 GMT+02:00 Liu Hao : > On 2017/4/6 20:47, Kai Tietz wrote: >> True. The reason why we prefer such patter is that it works in both >> languages as desired. Otherwise we would be in need to write >> different variants for the languages C/C++. This looks backward, and >> it still doesn't make sure that there might be warnings emitted for C, >> or C++ doing const casts. > The warning about casting away const-ness can be enabled on GCC6 using > `-Wcast-qual` (I am not sure about other versions). But as long as the > header file is in a system directory GCC is smart enough to not warn > about it even if our user enable that warning, unless `-Wsystem-headers` > is also given. > > -- > Best regards, > LH_Mouse True, that there are flags to turn such warnings off. Each compiler has its own variants for this. But well, why we should rely on such things. As you already mentioned, are our headers system ones, and therefore as silent as possible. Nothing is worse in experience to users, if they suddenly see warnings, they don't want to see. And that all because they enabled some warning flags for "their" code. Cheers, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
2017-04-06 14:47 GMT+02:00 Kai Tietz : > 2017-04-06 13:38 GMT+02:00 Norbert Pfeiler > : >> I’m pretty sure that cast via union is UB in C++ whereas C-style casting >> away constness isn’t (only writing to the resulting object would be) but it >> may result in compilers issuing warnings about style (because C++ has >> const_cast). Hmm, undefined behavior??? no, this is pretty well defined behavior. In C++ world a union cast is pretty much the same as a reinterpret_cast (or a C style cast without conversion operator). And a const_cast is just a smaller set out of the realm of reinterpret_cast. Cheers, Kai -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
2017-04-06 13:38 GMT+02:00 Norbert Pfeiler
:
> I’m pretty sure that cast via union is UB in C++ whereas C-style casting
> away constness isn’t (only writing to the resulting object would be) but it
> may result in compilers issuing warnings about style (because C++ has
> const_cast).
>
> Best, Norbert.
True. The reason why we prefer such patter is that it works in both
languages as desired. Otherwise we would be in need to write
different variants for the languages C/C++. This looks backward, and
it still doesn't make sure that there might be warnings emitted for C,
or C++ doing const casts.
Cheers,
Kai
> Kai Tietz schrieb am Do., 6. Apr. 2017 um
> 11:50 Uhr:
>
>> A cast via union looks like this:
>> type1 *foo(const type1 *my_const_ptr)
>> {
>> union {
>> type1 *t1;
>> const type1 *ct1;
>> } v;
>> v.ct1 = my_const_ptr;
>> return v.t1;
>> }
>>
>> The advantage of such a pattern is that no type conversion
>> errors/warnings are shown. So for casting from const to none-const,
>> this variant is to be preferred. (and it works for C, and C++!!!)
>>
>> Cheers,
>> Kai
>>
>> 2017-04-05 15:51 GMT+02:00 Mateusz Mikuła :
>> >> Hmm, using here "wchar_t *" as cast looks wrong. Actually we should
>> >> use anyway PUWSTR_C instead.
>> > I noticed it a bit too late and sent another patch casting to PUWSTR_C.
>> >> Nevertheless we can have here a const/none-const conversion (means
>> >> const specifiers for C-runtime function isn't regarded right?). I
>> >> would suggest to introduce a union-cast instead to avoid further
>> >> warnings instead.
>> > Conversion from const pointer to normal pointer is definitely unsafe but
>> > that's probably what GCC just did.
>> > I'm unsure what you mean by "union-cast" but you can commit your fix.
>> >
>> >
>> >
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
A cast via union looks like this:
type1 *foo(const type1 *my_const_ptr)
{
union {
type1 *t1;
const type1 *ct1;
} v;
v.ct1 = my_const_ptr;
return v.t1;
}
The advantage of such a pattern is that no type conversion
errors/warnings are shown. So for casting from const to none-const,
this variant is to be preferred. (and it works for C, and C++!!!)
Cheers,
Kai
2017-04-05 15:51 GMT+02:00 Mateusz Mikuła :
>> Hmm, using here "wchar_t *" as cast looks wrong. Actually we should
>> use anyway PUWSTR_C instead.
> I noticed it a bit too late and sent another patch casting to PUWSTR_C.
>> Nevertheless we can have here a const/none-const conversion (means
>> const specifiers for C-runtime function isn't regarded right?). I
>> would suggest to introduce a union-cast instead to avoid further
>> warnings instead.
> Conversion from const pointer to normal pointer is definitely unsafe but
> that's probably what GCC just did.
> I'm unsure what you mean by "union-cast" but you can commit your fix.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
Hmm, using here "wchar_t *" as cast looks wrong. Actually we should
use anyway PUWSTR_C instead.
Nevertheless we can have here a const/none-const conversion (means
const specifiers for C-runtime function isn't regarded right?). I
would suggest to introduce a union-cast instead to avoid further
warnings instead.
Regards,
Kai
2017-04-05 15:06 GMT+02:00 Mateusz Mikuła :
> Hmm, somehow Sourcefore has lost track on this thread (you can see
> patch on the mailing list website).
>
> This time sending it as both attachment and text.
>
> From f3febf9542a6664eedc384b0d2bf63411477e141 Mon Sep 17 00:00:00 2001
> From: Mateusz Mikula
> Date: Mon, 3 Apr 2017 13:36:36 +0200
> Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
> wchar_t *
>
> Clang doesn't allow implicit conversion form 'const wchar_t *' to
> 'wchar_t *'
>
> Signed-off-by: Mateusz Mikula
> ---
> mingw-w64-headers/include/stralign.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mingw-w64-headers/include/stralign.h
> b/mingw-w64-headers/include/stralign.h
> index 9b5637d6..cdb81438 100644
> --- a/mingw-w64-headers/include/stralign.h
> +++ b/mingw-w64-headers/include/stralign.h
> @@ -118,11 +118,11 @@ extern "C" {
>
> #ifndef __CRT__NO_INLINE
>__CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
> -if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
> +if(WSTR_ALIGNED(String)) return (wchar_t
> *)wcschr((PCWSTR)String,Character);
> return (PUWSTR_C)uaw_wcschr(String,Character);
>}
>__CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
> -if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
> +if(WSTR_ALIGNED(String)) return (wchar_t
> *)wcsrchr((PCWSTR)String,Character);
> return (PUWSTR_C)uaw_wcsrchr(String,Character);
>}
> #if defined(__cplusplus) && defined(_WConst_Return)
> --
> 2.12.1
>
>
> -- Original Message --
> Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
> ua_wcsrchr returns to wchar_t *
> Date: Wed, 5 Apr 2017 14:26:50 +0200
> To: Mingw-w64-public
> From: Kai Tietz
>> Hello Mateusz,
>>
>> could you please re-attach, or simply inline patch to this mail?
>>
>> Thanks in advance,
>> Kai
>>
>> 2017-04-05 14:08 GMT+02:00 Mateusz Mikuła :
>>> Ping, looks like it slipped unnoticed.
>>>
>>>
>>>
>>>
>>> -- Original Message --
>>> Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
>>> wchar_t *
>>> Date: Mon, 3 Apr 2017 14:01:00 +0200
>>> To: Mingw-w64-public
>>> From: Mateusz Mikuła
>>>> I made another attempt to build libc++ with mingw-w64 and stumbled
>>>> across Clang errors:
>>>>
>>>> |D:\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114:
>>>> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error:
>>>> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
>>>> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
>>>> return wcschr((PCWSTR)String,Character);
>>>> ^~~~
>>>> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:125:37: error:
>>>> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
>>>> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
>>>> return wcsrchr((PCWSTR)String,Character); You can see here function
>>>> that should return PUWSTR_C (aka ||'wchar_t *') returns ||'const wchar_t
>>>> *|' instead.
>>>>
>>>> This patch solved error for Clang and caused no errors or warning for GCC.
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *
Hello Mateusz, could you please re-attach, or simply inline patch to this mail? Thanks in advance, Kai 2017-04-05 14:08 GMT+02:00 Mateusz Mikuła : > Ping, looks like it slipped unnoticed. > > > > > -- Original Message -- > Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to > wchar_t * > Date: Mon, 3 Apr 2017 14:01:00 +0200 > To: Mingw-w64-public > From: Mateusz Mikuła >> >> I made another attempt to build libc++ with mingw-w64 and stumbled >> across Clang errors: >> >> |D:\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114: >> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error: >> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *') >> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String)) >> return wcschr((PCWSTR)String,Character); >> ^~~~ >> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:125:37: error: >> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *') >> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String)) >> return wcsrchr((PCWSTR)String,Character); You can see here function >> that should return PUWSTR_C (aka ||'wchar_t *') returns ||'const wchar_t *|' >> instead. >> >> This patch solved error for Clang and caused no errors or warning for GCC. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] (again) Use LPCVOID instead of 'const LPVOID' for VerQueryValue.
Ok for master. Thanks, Kai 2017-03-17 5:06 GMT+01:00 Liu Hao : > On 2017/3/17 11:09, David Grayson wrote: >> Here is that patch again. Thanks! > These new prototypes match > https://msdn.microsoft.com/en-us/library/windows/desktop/ms647464.aspx , > so I think it is ok to apply, no? > > -- > Best regards, > LH_Mouse > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)
Hello, If you want to solve this, you will need to use the large Code model. Cheers, Kai Am 15.02.2017 06:43 schrieb "Roger Pack" : > On 2/8/17, Ricardo Constantino wrote: > > On 8 February 2017 at 02:55, Liu Hao wrote: > > > >> On 2017/2/8 1:45, Ricardo Constantino wrote: > >> > Should be fixed with > >> > https://github.com/Alexpux/MINGW-packages/commit/ba282a67e, but I > >> thought > >> > someone would've reported it to upstream by now? > >> Probably you could comment this PR > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506. > >> > > > > >From the amount of dev response to Roger's comment I figure any further > > response to be pointless. > > I can't even explain why my patch fixes it, that's why I didn't bother > > making an issue. I literally > > just copied gcc's fix to cygwin and added a 64-bit check because only > > 64-bit had an issue. > > Oddly, seems it is actually caused (aggravated by? related to?) this ld > flag: > --image-base,0x14000 > https://trac.ffmpeg.org/ticket/5895 > FWIW...so possibly not actually a bug [?] > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Erroneous "out of memory" using LTO
Hello, First "-Os" is indeed optimization for "size", not for "speed". But well, later is sometimes true too. At least for programs benefiting from cpu cache. :) 2017-03-15 4:06 GMT+01:00 Riot : > Thanks for the detailed response Ruben, I appreciate it. > > We do use gold on Linux and perhaps that's the reason we don't encounter > these sorts of issues, although we're building with 64bit tools there in > any case, so perhaps we would only see them in a purely 32bit build > environment. Well, there was in the past the idea to create for pe-coff an equivalent to gold (should be named "cold", isn't it? :) ). As gold is not designed to be usable for pe-coff targets, this is linker is sadly no option here. > We've looked at TDM64-GCC before for building on Windows, but we've been > somewhat put off by its slower update rate than Mingw-w64 - their latest > gcc version is currently 5.1.0, whereas we're currently building with 6.3.0 > on Windows and using newer features. I'd like to stay with this project > since we've had such good results with Mingw-w64 for the past number of > years, and this is a very minor hiccup that we can work around; I was > mostly concerned that it may have been a Mingw-w64-specific bug, as we > could only make it manifest on Windows. The LTO-ing got some years ago some improvements for pe-coff. Sadly I don't have the time to improve situation on this. But as Ruben already pointed out, LTO is still a cane of worms ... but there are less worms nowadays ... > As you say, I'm not entirely enthused by the prospect of digging into ld's > code, and if the issue is indeed upstream, I don't see much hope of having > it fixed in the case of an issue I can only manifest on Windows, and where > the minimal testcase appears to be a project with ~700MB of (closed) > source. So I'll stick with our workaround for now, in exchange for a very > small performance penalty. Thank you for clearing up the likely culprit, > and setting my mind at ease, in any case. True. Btw it just reminds me that you can lower LTO's memory consumption by avoiding to use debug information in object files ... I know that there were some time ago work spend on this item upstream, but AFAIU the issue still exists. > You mentioned a Mingw-w64 64bit to 32bit cross-compiler; it sounds like > that may avoid any such issues in future for us - do you happen to know if > anyone is building such a thing regularly and where? Well, to build gcc as cross compiler is no rocket science ... I know that cygwin people build a cross mingw-w64 32-bit compiler on cygwin64, which is pretty close to what you want. You could ask JonY. I think he does those mingw-w64 cross-compilers for the cygwin people, so he might have some skills to help you on this. Regards, Kai > Regards, > Riot > > On 14 March 2017 at 22:56, Ruben Van Boxem wrote: > >> The default values can be found in >> https://github.com/gcc-mirror/gcc/blob/master/gcc/params.def >> >> For example, but I guess you already knew where to find those. >> >> Op 14 mrt. 2017 11:55 p.m. schreef "Ruben Van Boxem" < >> vanboxem.ru...@gmail.com>: >> >> > Additionally, if you look at the default values of the parameters you're >> > changing, it seems you're stretching the (compiler) implementation quite >> a >> > bit, so I'm not sure why you are surprised that the compiler can't handle >> > it. It seems like you're loading ten blocks of granite into a minivan and >> > surprised it won't budge. >> > >> > I'm not criticising you, just telling you you're using the tools outside >> > of their design specifications. >> > >> > Ruben >> > >> > Op 14 mrt. 2017 11:48 p.m. schreef "Ruben Van Boxem" < >> > vanboxem.ru...@gmail.com>: >> > >> >> Hello again, >> >> >> >> Op 14 mrt. 2017 9:26 p.m. schreef "Riot" : >> >> >> >> On 14 March 2017 at 18:53, Ruben Van Boxem >> >> wrote: >> >> >> >> > These options look quite... inefficient... and frankly suboptimal. I >> >> hope >> >> > you do regular benchmarking to see if these are actually any/much >> better >> >> > than default -O2 -march=native 'or whatever). >> >> >> >> Yes, we benchmark extensively, and we would not use those options if we >> >> didn't see speed increases. However, that is not relevant to the topic >> >> here, which is that certain compiler options appear to cause an >> erroneous >> >> claim of memory exhaustion when memory is not, in fact, exhausted. >> >> >> >> >> >> Just making sure. Most people don't know what they're doing, and I'm >> glad >> >> you seem to know what you're doing. >> >> >> >> >> >> Inlining everything is not >> >> > the best optimization. >> >> >> >> >> >> I didn't claim it was. Again, this is a bit off topic. >> >> >> >> >> >> > Sometimes, -Os (optimizing for speed) can generate >> >> > faster code than inlined and loop unrolled -O2, because of cache >> >> misses. In >> >> > any case, I hope you have hard numbers to back up these very weird >> >> options. >> >> > >> >> >> >> You mean "optimising for
Re: [Mingw-w64-public] [PATCH] Add sysexits.h, err.h, err functions
Hello Kelvin, I agree that this API is pretty useful, but it nothing we want to add this way to our standard libraries. Could could place it to our library section instead. It would be a failure to add it by default to our crt, as those symbols easily conflict with user code. Regards, Kai 2017-03-08 15:12 GMT+01:00 Kelvin Sherlock : > > This adds the very useful sysexits.h, err.h, and err.c (err(3), errc(3), > errx(3), warn(3), warnc(3), warnx(3), etc). > getopt(3) previously included its own static copy of warn(), so that was > updated to use the real thing. > --- > mingw-w64-crt/Makefile.am| 2 +- > mingw-w64-crt/misc/err.c | 188 > +++ > mingw-w64-crt/misc/getopt.c | 25 +- > mingw-w64-headers/crt/err.h | 61 + > mingw-w64-headers/crt/sysexits.h | 116 > 5 files changed, 367 insertions(+), 25 deletions(-) > create mode 100644 mingw-w64-crt/misc/err.c > create mode 100644 mingw-w64-headers/crt/err.h > create mode 100644 mingw-w64-headers/crt/sysexits.h > > > -- > Announcing the Oxford Dictionaries API! The API offers world-renowned > dictionary content that is easy and intuitive to access. Sign up for an > account today to start using our lexical data to power your apps and > projects. Get started today and enter our developer competition. > http://sdm.link/oxford > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] objidlbase.idl: Added IAgileReference declaration.
Patch is ok for apply. Thanks, Kai 2017-03-08 12:29 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-headers/include/objidlbase.idl | 6 ++ > 1 file changed, 6 insertions(+) > > > > -- > Announcing the Oxford Dictionaries API! The API offers world-renowned > dictionary content that is easy and intuitive to access. Sign up for an > account today to start using our lexical data to power your apps and > projects. Get started today and enter our developer competition. > http://sdm.link/oxford > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] libuuid.a: Added CLSID_StdGlobalInterfaceTable.
Ok, please apply. Thanks, Kai 2017-03-08 12:29 GMT+01:00 Jacek Caban : > Signed-off-by: Jacek Caban > --- > mingw-w64-crt/libsrc/uuid.c | 1 + > 1 file changed, 1 insertion(+) > > > > -- > Announcing the Oxford Dictionaries API! The API offers world-renowned > dictionary content that is easy and intuitive to access. Sign up for an > account today to start using our lexical data to power your apps and > projects. Get started today and enter our developer competition. > http://sdm.link/oxford > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Why is `ChangeWindowMessageFilterEx` defined in lib32, but not lib64?
Not sure, if this new export was already added. If not, prepare a patch, and send it to ML. Regards, Kai 2017-02-19 17:17 GMT+01:00 Ruslan Garipov : > Hello! > > File 'mingw-w64-v5.0.1/mingw-w64-crt/lib32/user32.def' has exporting > declaration of function [ChangeWindowMessageFilterEx][1], but file > 'mingw-w64-v5.0.1/mingw-w64-crt/lib64/user32.def' **does not**. Why? > > Now, having MINGW targeting `x86_64-w64-mingw32' I can't built a program > that uses `ChangeWindowMessageFilterEx`. > > Thanks! > > [1]: > https://msdn.microsoft.com/en-us/library/windows/desktop/dd388202(v=vs.85).aspx > "ChangeWindowMessageFilterEx function" > > -- > Yours truly, > Ruslan Garipov . > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
