Re: [Mingw-w64-public] [PATCH] headers: Use asm() for redirecting time functions, instead of inline functions

[Kai Tietz via Mingw-w64-public]

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 
> 

Re: [Mingw-w64-public] [PATCH] crt: Implement the __stpcpy_chk function

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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: Use __attribute__((force_align_arg_pointer)) for aligning the stack on entry

[Kai Tietz via Mingw-w64-public]

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 (, 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 ();
>{
> --
> 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] uianimation.idl: Added missing constants.

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

2018-02-23 10:56 GMT+01:00 Martin Storsjö <mar...@martin.st>:
> 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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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}`.

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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 1/4] dwrite.h: Added DWRITE_DECLARE_INTERFACE define.

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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.

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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, ...)
> +  {

Re: [Mingw-w64-public] [PATCH] headers: Remove an empty dxgi1_6.h

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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__, 

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

[Kai Tietz via Mingw-w64-public]

2017-11-21 11:36 GMT+01:00 Martin Storsjö <mar...@martin.st>:
> 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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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."

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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__

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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 += 

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

[Kai Tietz via Mingw-w64-public]

Hmm, I am not really good at choosing nice names.  But well, I would
vote for something like libmsvcrt_os.a

Cheers
Kai

2017-11-09 22:42 GMT+01:00 Martin Storsjö <mar...@martin.st>:
> 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

[Kai Tietz via Mingw-w64-public]

Hmm, I would prefer to have a configure option. But nevertheless all libraries
should be built regardless to this configure option, but under separate unique
names. The configure option should just decide, which msvc*/ucrt
library version should be copied as libmsvcrt.a library.

2017-11-09 15:59 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...: 

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

[Kai Tietz via Mingw-w64-public]

Patch looks better now. Please go ahead.

Thanks,
Kai

2017-11-09 11:02 GMT+01:00 Martin Storsjö :
> In msvcrt.dll, it only existed on i386. In the numbered msvcr* DLLs,
> it was present in all of them except msvcr80.dll for x86_64.
>
> Define __argv to use __p___argv().
>
> This 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) = 

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

[Kai Tietz via Mingw-w64-public]

Hmm, C99 support is pretty important for the gnu world.  Nevertheless
patch ok. Please go ahead.

Thanks,
Kai

2017-11-09 10:04 GMT+01:00 Martin Storsjö :
> When __USE_MINGW_ANSI_STDIO is defined, we still call the custom
> implementation bundled in libmingwex. (Redirecting this 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

[Kai Tietz via Mingw-w64-public]

Patch ok. Please go ahead.

Thanks,
Kai

2017-11-09 10:01 GMT+01:00 Martin Storsjö :
> Prior to unification of msvcrt.def.in, neither 32 or 64 bit x86
> did export this function. In practice, they seem to have existed
> since Vista.
>
> At this point, msvcrt.def.in should 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

[Kai Tietz via Mingw-w64-public]

Patch ok. Please go ahead.

Thanks,
Kai

2017-11-09 9:59 GMT+01:00 Martin Storsjö :
> Not all the variables that were listed seem to be exported from
> ucrtbase though, so only hook up those that do exist.
>
> Signed-off-by: Martin Storsjö 
> ---
> This was 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

[Kai Tietz via Mingw-w64-public]

Patch ok. Please go ahead.

Thanks,
Kai

2017-11-09 9:59 GMT+01:00 Martin Storsjö :
> This is in preparation for redefining these declarations for ucrtbase.
>
> Signed-off-by: Martin Storsjö 
> ---
> I don't think anyone actually has commented on this one yet, 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 

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

[Kai Tietz via Mingw-w64-public]

2017-11-09 9:18 GMT+01:00 Martin Storsjö :
> On Thu, 9 Nov 2017, Jacek Caban wrote:
>
>> On 08.11.2017 23:19, Martin Storsjö wrote:
>>>
>>> - Fix getopt by using __p___argv there instead of __argv, as Jacek
>>>   suggested. In order to do this, I ended up cleaning up a few other
>>>   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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

Well, I don't think it is necessary to provide them.

Thanks,
Kai

2017-08-21 15:00 GMT+02:00 Martin Storsjö <mar...@martin.st>:
> 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

[Kai Tietz via Mingw-w64-public]

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
>  

Re: [Mingw-w64-public] [PATCH 06/27] crt: Unify bcrypt.def for lib64 and libarm32

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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)
> -?OpenComponentLibrarySharedTS@@YAJPEBG0KPEAU_SECURITY_ATTRIBUTES@@JPEAPEAUIComponentRecords@@@Z
> +F_X64(?OpenComponentLibrarySharedTS@@YAJPEBG0KPEAU_SECURITY_ATTRIBUTES@@JPEAPEAUIComponentRecords@@@Z)
>  ; long __cdecl OpenComponentLibraryTS(unsigned short const * 
> __ptr64,long,struct IComponentRecords * __ptr64 * __ptr64)
> 

Re: [Mingw-w64-public] [PATCH 08/27] crt: Unify crypt32.def for lib64 and libarm32

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

Re: [Mingw-w64-public] [PATCH 03/18] crt: Add an initial libarm64 directory with def files

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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 restore_modified_sections to make sure we
>>> apply VirtualProtect to restore the whole modified region.
>>>
>>> Many thanks to Jonathan Yong and Kai Tietz for helpful discussions.
>
> --
> 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] __C_specific_handler accessible for __IA_64__ but not for __X86_64

[Kai Tietz via Mingw-w64-public]

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?

[Kai Tietz via Mingw-w64-public]

2017-06-22 18:41 GMT+02:00 Lev Serebryakov <l...@serebryakov.spb.ru>:
> 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.

[Kai Tietz via Mingw-w64-public]

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?

[Kai Tietz via Mingw-w64-public]

2017-06-22 14:19 GMT+02:00 Lev Serebryakov <l...@serebryakov.spb.ru>:
> 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.

[Kai Tietz via Mingw-w64-public]

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?

[Kai Tietz via Mingw-w64-public]

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?

[Kai Tietz via Mingw-w64-public]

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] [Patch] normalize strftime and strftime_l

[Kai Tietz via Mingw-w64-public]

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)

[Kai Tietz via Mingw-w64-public]

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

[Kai Tietz via Mingw-w64-public]

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