Re: [Mingw-w64-public] Rust test failure after some math functions were moved

[Mateusz Mikuła]

I don't know how we can check that.
The test that failed has nothing to do with math: 
https://github.com/rust-lang/rust/issues/2214 and I suppose lgamma was picked 
somewhat randomly as a function that requires FFI and should be universally 
available.

Moving sin and log internal implementations to libmsvcrt would help in this 
case but probably more functions would need similar change.

Dnia wtorek, 16 kwiecień 2024 17:34:31 (+02:00), Jacek Caban napisał(a):

> On 16.04.2024 17:29, philippe renon wrote:
> > Note that there are more math functions involved (not just sin).
> > See the commit that introduced the issue for a full list: 
> > https://github.com/mingw-w64/mingw-w64/commit/a64c1f4b969cff5f9e81c9a760117dc1b92d6ee1
> >
> 
> I know, but only the ones that depend on mingwex are a problem, are there 
> others like that?
> 
> 
> Jacek
> 
> 
> 
> ___
> 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] [PATCH] Fix UB in mkstemp retry loop

[Mateusz Mikuła]

Signed-off-by: Mateusz Mikuła 
---
 mingw-w64-crt/misc/mkstemp.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c
index 3b6246540..7291efcc8 100644
--- a/mingw-w64-crt/misc/mkstemp.c
+++ b/mingw-w64-crt/misc/mkstemp.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
 The mkstemp() function generates a unique temporary filename from template,
@@ -25,8 +26,8 @@
  */
 int __cdecl mkstemp (char *template_name)
 {
-int i, j, fd, len, index;
-unsigned int r;
+int j, fd, len, index;
+unsigned int i, r;

 /* These are the (62) characters used in temporary filenames. */
 static const char letters[] = 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
@@ -41,11 +42,8 @@ int __cdecl mkstemp (char *template_name)
 /* User may supply more than six trailing Xs */
 for (index = len - 6; index > 0 && template_name[index - 1] == 'X'; 
index--);

-/*
-Like OpenBSD, mkstemp() will try at least 2 ** 31 combinations before
-giving up.
- */
-for (i = 0; i >= 0; i++) {
+/* Like OpenBSD, mkstemp() will try 2 ** 31 combinations before giving up. 
*/
+for (i = 0; i <= INT_MAX; i++) {
 for(j = index; j < len; j++) {
 if (rand_s(&r))
 r = rand();
--
2.44.0.windows.1


___
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] Use rand_s in mkstemp function

[Mateusz Mikuła]

Dnia środa, 6 marzec 2024 10:09:30 (+01:00), Martin Storsjö napisał(a):

> On Mon, 4 Mar 2024, Martin Storsjö wrote:
> 
> > Looking closer at our mkstemp implementation, we have this loop:
> >
> >/*
> >Like OpenBSD, mkstemp() will try at least 2 ** 31 combinations before
> >giving up.
> > */
> >for (i = 0; i >= 0; i++) {
> >for(j = index; j < len; j++) {
> >template_name[j] = letters[rand () % 62];
> >}
> >fd = _sopen(template_name,
> >_O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
> >_SH_DENYNO, _S_IREAD | _S_IWRITE);
> >if (fd != -1) return fd;
> >if (fd == -1 && errno != EEXIST) return -1;
> >}
> >
> > This should retry an absolutely insane number of times, so as long as one 
> > process finds a unique file name and stops iterating, the other parallel 
> > process should also find a unique one soon after, one would expect.
> >
> > So if this fails, it looks like something is fishy here; if we have this 
> > clash, do we hit the "if (fd == -1 && errno != EEXIST) return -1;" case 
> > directly on the first iteration?
> 
> I tried reproducing this myself. I was able to hit the error, but only very 
> very rarely (I only reproduced it twice while running these loops for an hour 
> or two)).
> 
> The loop does work as expected, normally - in most cases of collisions, we do 
> continue iterating. Only in a very very small fraction of cases, we end up 
> with errno set to something else than EEXIST, e.g. EACCES. And overall, 
> erroring out on EACCES is the right thing to do, otherwise we'd loop (near) 
> infinitely if trying to create a temp file in a directory without write 
> permission.
> 
> So that clarifies the mystery to me. And the suggested fix of using rand_s() 
> sounds good to me, but we should keep a fallback to rand().
> 
> I'll post a new patch with that behaviour implemented, and with a slightly 
> updated commit message.
> 
> // Martin
> 
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> 


For some mysterious reason I was unable to reproduce the problem with 
toolchains provided by MSYS2.

However using https://github.com/niXman/mingw-builds-binaries or my own 
toolchain built with crosstool-ng it took less than a minute for me using 
provided loops.

Even GitHub actions reproduced the issue within 5 minutes: 
https://github.com/mati865/ehuss_test/actions/runs/7291015249/job/19869073666

Thank you for picking this up though.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Use rand_s in mkstemp function

[Mateusz Mikuła]

rand is not random enough and may lead to clashing temporary directories
with multiple parallel link processes as it was observed on Rust's CI.

It can be reproduced with these commands (run them all in without long pauses):


for n in {1..15000}; do rm -f lib/libLLVMAVRAsmParser.a && \
ar qc lib/libLLVMAVRAsmParser.a 
lib/Target/AVR/AsmParser/CMakeFiles/LLVMAVRAsmParser.dir/AVRAsmParser.cpp.obj 
&& \
ranlib.exe lib/libLLVMAVRAsmParser.a; done &

for n in {1..15000}; do rm -f lib/libLLVMSparcCodeGen.a && \
ar qc lib/libLLVMSparcCodeGen.a 
lib/Target/Sparc/CMakeFiles/LLVMSparcCodeGen.dir/*.obj && \
ranlib.exe lib/libLLVMSparcCodeGen.a; done

echo "done"
fg

Before the patch it will fail with an error: ranlib.exe: could not create 
temporary file whilst writing archive: no more archived files.

The changes in this patch were proposed by Josh Stone on Rust's Zulip server 
and I was asked to forward it.

Co-Authored-By: Josh Stone 
Signed-off-by: Mateusz Mikuła 
---
 mingw-w64-crt/misc/mkstemp.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-crt/misc/mkstemp.c b/mingw-w64-crt/misc/mkstemp.c
index 6b327f2fc..1698f49f4 100644
--- a/mingw-w64-crt/misc/mkstemp.c
+++ b/mingw-w64-crt/misc/mkstemp.c
@@ -1,3 +1,4 @@
+#define _CRT_RAND_S
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 int __cdecl mkstemp (char *template_name)
 {
 int i, j, fd, len, index;
+unsigned int r;

 /* These are the (62) characters used in temporary filenames. */
 static const char letters[] = 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
@@ -45,7 +47,8 @@ int __cdecl mkstemp (char *template_name)
  */
 for (i = 0; i >= 0; i++) {
 for(j = index; j < len; j++) {
-template_name[j] = letters[rand () % 62];
+if (rand_s (&r)) return -1;
+template_name[j] = letters[r % 62];
 }
 fd = _sopen(template_name,
 _O_RDWR | _O_CREAT | _O_EXCL | _O_BINARY,
--
2.43.0.windows.1


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Migration from SF and port from Autotools

[Mateusz Mikuła]

Dnia wtorek, 4 kwiecień 2023 20:37:20 (+02:00), Jacek Caban via 
Mingw-w64-public napisał(a):

> On 3/31/23 18:24, NightStrike wrote:
> >
> >
> > On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public  wrote:
> >
> > On 3/20/23 16:44, مهدي شينون wrote:
> > > Hi everyone,
> > >
> > >
> > > Could you please consider migrating your project to another host
> > other
> > > than sourcefoge where people could file bugs, propose changes and
> > > discuss things (like GitHub ot GitLab).
> > >
> > > Using mailing-list for that is a way that's not suitable for young
> > > generation (including me).
> > >
> > > Many people try to report bugs or propose changes but ended up
> > ignored
> > > because of this insist on using this outdated technology!
> >
> >
> > We had similar talks in Wine for years and we finally decided
> > decided to
> > migrate to Gitlab last year. I think it was a good choice. We had it
> > running parallel to ML as an experiment first, here is the summary:
> >
> > https://www.winehq.org/pipermail/wine-devel/2022-June/220008.html
> >
> > I think most of it would apply to mingw-w64 as well. I'd like to
> > especially point CI: Gitlab makes it easy to set up CI and mingw-w64
> > could really use one. It's esp. nice for reviewers: by the time
> > you look
> > at the patch, you already know that it doesn't break the build.
> >
> >
> > The use of a hosted solution vs making lists for patches is orthogonal to 
> > not using SF. We could use any of the many services SF offers, and I pushed 
> > this hard over the years, but people like mailing list patches. Part of it 
> > is old habits, part of it is accessibility. Patch commenting on a website 
> > with markdown is neat and useful, but not very accessible.
> 
> 
> It's not website nor markdown that I care about (in fact, UI is not really 
> Gitlab's strong side). Better git utilization is nice to have. It also makes 
> CI easy to automate. Ideally CI would catch problems very early, with no need 
> to bother reviewers.
> 
> 
> > As for CI, remember that to have effective CI for us requires building the 
> > whole toolchain. We used to do this daily with a buildbot service set up by 
> > Mook and me, served by ReactOS, and run on donated hardware. Mook left, 
> > react stopped giving us the server, and donors stopped donating.
> >
> > I'm working with MJW to get a builder running on the SW BB. That should 
> > take care of this requirement, but mind you that native builds can take 
> > days to finish.
> 
> 
> It's sad that native builds take days to finish... Is there any hope that it 
> will improve? Is it a matter of Cygwin/msys being slow? If yes, can it be 
> optimized? If not...
> 

Using niXman scripts GNU build takes with free GitHub builders it takes 4-6 
hours per build (they run parallel though): 
https://github.com/mati865/mingw-builds/actions/runs/4526815011
AFAICT a lot of this time is wasted by inefficiency fork emulation in Cygwin (I 
don't blame them though) which is used by autotools a lot.

I cannot compare LLVM directly as I build it only locally (and I don't build 
GNU toolchain locally) but it used to take about half of the time few years ago,

> 
> Anyway, for pre-commit CI, we don't need a full toolchain bootstrap. 
> Rebuilding mingw-w64 parts using precompiled toolchains alone would be nice. 
> If we'd want to catch more problems, we could use that to also build things 
> like libgcc, libstc++, compiler-rt, libc++ and maybe some more light but 
> interesting external projects. Ideally using both GCC and LLVM precompiled 
> toolchains.
> 
> 
> >
> > Wine uses self-hosted Gitlab instance, which solves the problem of
> > dependence on third party host. Having its own self-hosted
> > instance just
> > for mingw-w64 would probably be too much overhead for mingw-w64
> > project,
> > so if we decided to migrate, we'd need to pick one of externally
> > hosted
> > solutions.
> >
> >
> > BTW, SF mailing lists are especially not friendly for patches with
> > its
> > automatic footer messing inline patches and some attachments being
> > silently dropped, depending on their extensions.
> >
> >
> > That's configurable. If there's a mime type that needs adding, I can add it.
> 
> 
> How about allowing all MIME types? And for inline patches, can you disable 
> all mail body modifications?
> 
> 
> >
> > As I pointed out previously, the use of auto tools by mingw-w64 doesn't 
> > stop anyone from using whatever they want in their own project. If you're 
> > building mingw-w64, you're building gcc anyway, so what difference does it 
> > make? You need a GNU environment (that's the G in our name after all!), so 
> > running a configure script isn't really an additional requirement. Whereas 
> > cmake would absolutely be a new requirement.
> 
> 
> LLVM is well supported by mingw-w64 for years now

Re: [Mingw-w64-public] [PATCH] crt: Use only __ImageBase symbol in mingw-w64 code

[Mateusz Mikuła]

On Sat., 19 Nov 2022 11:54 Pali Rohár  wrote:

> On Saturday 19 November 2022 17:12:12 LIU Hao wrote:
> > 在 2022-11-18 23:40, Pali Rohár 写道:
> > > GNU LD provides __ImageBase symbol since 2.19. This is standard windows
> > > symbol and should be used instead of custom gnu _image_base__ symbol.
> > >
> > > For compatibility with older GNU LD versions, define __ImageBase as
> weak
> > > alias to _image_base__ symbol.
> > >
> > > This allows to remove all #ifdef hacks for older GNU LD versions as
> with
> > > this change __ImageBase works correctly with all GNU LD versions.
> > > ---
> >
> > Generally speaking, one shouldn't use weak symbols when targeting
> Windows. I
> > haven't investigated though, but many times weak symbols result in null
> or
> > faulty addresses.
>
> Interesting, I did not know that there are issues with weak symbols. All
> my tests with weak symbols passed, I have not spotted any issue.
>
> They were/are problematic mostly when using GCC+ld.bfd and putting weak
symbols inside DLL
to later use it from other DLL or executable. There have been multiple
patches over the years that
improve this situation but IIRC using them inside static libraries is
mostly fine with newer Binutils.
Still requiring Binutils with working weak symbols would in fact drop
support for more versions
than just hardcoding 2.19. One of the serious issues was fixed just in
Binutils 2.35.
Interestingly most of these issues do not apply with GCC+LLD or
Clang+ld.bfd and I think
none apply to Clang+LLD.

> > Thus, weak symbols are unacceptable; but removal of references to
> > `__image_base__` seems fine, if dropping support for binutils 2.18 is
> > acceptable. BTW 2.19 was released in 2008 [1].
> >
> > [1] https://lists.gnu.org/archive/html/info-gnu/2008-10/msg00014.html
>
> Another option is to detect at ./configure time if linker accepts
> __ImageBase symbol. And if not then define __ImageBase as normal
> (non-weak) symbol. Should be pretty simple.
>
>
> ___
> 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

Re: [Mingw-w64-public] [PATCH 0/2] Update fwpuclnt exports and build for arm64

[Mateusz Mikuła]

czw., 10 mar 2022, 14:05 użytkownik Martin Storsjö 
napisał:

> On Wed, 9 Mar 2022, Jeremy Drake via Mingw-w64-public wrote:
>
> > It turns out that "cargo" links with fwpuclnt, and efforts to get rust
> > working for aarch64-pc-windows-gnu have hit the lack of fwpuclnt.a for
> > arm64.
>
> I'm curious - what does cargo do with this DLL?
>

Likely nothing, it is hardwired in winapi to always link it.

> The second commit is the regeneration of 'automake', I am not sure if
> > that is desired so it was split into a separate commit that can be
> > applied or not.
>
> Thanks for splitting it out; we generally don't send those patches to the
> list, but whoever applies the patch regenerates files as necessary.
>
> > mingw-w64-crt/Makefile.in |  51 +++---
> > .../{libarm32 => lib-common}/fwpuclnt.def |  28 +++-
> > mingw-w64-crt/lib32/fwpuclnt.def  | 149 +-
> > mingw-w64-crt/lib64/fwpuclnt.def  | 146 -
> > mingw-w64-crt/libarm64/Makefile.am|   1 +
> > 5 files changed, 198 insertions(+), 177 deletions(-)
> > rename mingw-w64-crt/{libarm32 => lib-common}/fwpuclnt.def (89%)
> > delete mode 100644 mingw-w64-crt/lib64/fwpuclnt.def
>
> The patch looks sensible to me, but yes, the please add the corresponding
> stdcall decoration for the functions that forward to NtClose.
>
> // Martin
>
>
>
> ___
> 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

Re: [Mingw-w64-public] [PATCH] Enable __MINGW_FORCE_SYS_INTRINS for Clang

[Mateusz Mikuła]

Sorry for the late reply.

Your description sounds good for me.
Since I don't have write access can I ask you to commit it with your
description?

Thanks
Mateusz

śr., 31 mar 2021 o 13:53 Martin Storsjö  napisał(a):

> On Mon, 29 Mar 2021, Mateusz Mikuła wrote:
>
> > See https://github.com/msys2/CLANG-packages/issues/6 for the details
> > ---
> > mingw-w64-headers/crt/intrin.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/mingw-w64-headers/crt/intrin.h
> b/mingw-w64-headers/crt/intrin.h
> > index 4e840fab..250c25b2 100644
> > --- a/mingw-w64-headers/crt/intrin.h
> > +++ b/mingw-w64-headers/crt/intrin.h
> > @@ -47,10 +47,10 @@
> >  * C++ linkage (when GCC headers are explicitly included before
> intrin.h),
> > but at least their
> >  * guards will prevent duplicated declarations and avoid conflicts.
> >  *
> > - * On GCC 4.9 we may always include those headers. On older GCCs, we may
> > do it only if CPU
> > + * On GCC 4.9 and Clang we may always include those headers. On older
> > GCCs, we may do it only if CPU
> >  * features used by them are enabled, so we need to check macros like
> > __SSE__ or __MMX__ first.
> >  */
> > -#if __MINGW_GNUC_PREREQ(4, 9)
> > +#if __MINGW_GNUC_PREREQ(4, 9) || defined(__clang__)
> > #define __MINGW_FORCE_SYS_INTRINS
> > #endif
> >
> > --
> > 2.30.2.windows.1
>
> Thanks, this patch looks good to me, but it'd be nice to include a bit
> more details in the commit message, i.e. indicating that our definition of
> e.g. __m64 (which we include if __MMX__ isn't defined) conflicts with the
> one from mmintrin.h, which is included implicitly via x86intrin.h. With
> clang, it seems to be ok to include the *mmintrin.h headers even for
> instruction sets not currently enabled, e.g. if building with -march=i686
> which disables MMX and SSE, which otherwise normally are enabled.
>
>
> // Martin
>
> ___
> 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] [PATCH] Enable __MINGW_FORCE_SYS_INTRINS for Clang

[Mateusz Mikuła]

 See https://github.com/msys2/CLANG-packages/issues/6 for the details
---
 mingw-w64-headers/crt/intrin.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
index 4e840fab..250c25b2 100644
--- a/mingw-w64-headers/crt/intrin.h
+++ b/mingw-w64-headers/crt/intrin.h
@@ -47,10 +47,10 @@
  * C++ linkage (when GCC headers are explicitly included before intrin.h),
but at least their
  * guards will prevent duplicated declarations and avoid conflicts.
  *
- * On GCC 4.9 we may always include those headers. On older GCCs, we may
do it only if CPU
+ * On GCC 4.9 and Clang we may always include those headers. On older
GCCs, we may do it only if CPU
  * features used by them are enabled, so we need to check macros like
__SSE__ or __MMX__ first.
  */
-#if __MINGW_GNUC_PREREQ(4, 9)
+#if __MINGW_GNUC_PREREQ(4, 9) || defined(__clang__)
 #define __MINGW_FORCE_SYS_INTRINS
 #endif

--
2.30.2.windows.1

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Enable __MINGW_FORCE_SYS_INTRINS for Clang

[Mateusz Mikuła]

See https://github.com/msys2/CLANG-packages/issues/6 for the details
---
 mingw-w64-headers/crt/intrin.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/crt/intrin.h b/mingw-w64-headers/crt/intrin.h
index 4e840fab..250c25b2 100644
--- a/mingw-w64-headers/crt/intrin.h
+++ b/mingw-w64-headers/crt/intrin.h
@@ -47,10 +47,10 @@
  * C++ linkage (when GCC headers are explicitly included before intrin.h),
but at least their
  * guards will prevent duplicated declarations and avoid conflicts.
  *
- * On GCC 4.9 we may always include those headers. On older GCCs, we may
do it only if CPU
+ * On GCC 4.9 and Clang we may always include those headers. On older
GCCs, we may do it only if CPU
  * features used by them are enabled, so we need to check macros like
__SSE__ or __MMX__ first.
  */
-#if __MINGW_GNUC_PREREQ(4, 9)
+#if __MINGW_GNUC_PREREQ(4, 9) || defined(__clang__)
 #define __MINGW_FORCE_SYS_INTRINS
 #endif

--
2.30.2.windows.1

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Cross compiling a GTK app for windows from Ubuntu

[Mateusz Mikuła]

Hello



You also need GTK libraries built for mingw-w64.

On Debian (and therefore Ubuntu) AFAIK there are no prebuilt packages so
you have to build them on your own.

Some other distributions have official and unofficial packages:

https://pkgs.org/download/mingw-w64-gtk3

https://pkgs.org/download/mingw64-gtk3

wt., 9 mar 2021 o 01:31 relay.public.ad...@outlook.com <
relay.public.ad...@outlook.com> napisał(a):

> Hello
>
> I was trying to cross compile a Gtk-rs application for windows but the
> linker complains that it cannot find some gtk libraries. Note that the same
> application will run when compiled for native linux:
>
>
> error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
>   |
>   = note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin"
> "-Wl,--nxcompat" "-Wl,--dynamicbase" "-Wl,--disable-auto-image-base" "-m64"
> "-Wl,--high-entropy-va"
> "/home/bruce3434/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsbegin.o"
> "-L"
> "/home/bruce3434/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.0.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.1.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.10.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.11.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.12.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.13.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.14.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.15.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.2.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.3.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.4.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.5.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.6.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.7.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.8.rcgu.o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.gtkrscross.d6u0ovm3-cgu.9.rcgu.o"
> "-o"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.exe"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/gtkrscross-207d51d3ed9c4ee6.106ulhbr17826qq7.rcgu.o"
> "-Wl,--gc-sections" "-nodefaultlibs" "-L"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps"
> "-L" "/home/bruce3434/proj/gtkrscross/target/release/deps" "-L"
> "/home/bruce3434/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-x86_64-pc-windows-gnu-0.4.0/lib"
> "-L"
> "/home/bruce3434/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib"
> "-Wl,-Bstatic"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libgtk-8c74b22985e5df54.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libgdk-34de63afc0761694.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libpango-ad062bbe3fc0eb7b.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libgdk_pixbuf-0f2bb192ac593077.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libcairo-e9eb6644f42e9c76.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libatk-1e6e83434be2309d.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libgtk_sys-33d624969fd3014f.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libatk_sys-44518a8f4f7f1253.rlib"
> "/home/bruce3434/proj/gtkrscross/target/x86_64-pc-windows-gnu/release/deps/libgdk_sys-afa127cebea12e02.r

Re: [Mingw-w64-public] Build error with mingw-8.0.0 and gcc-11: multiple definition of `__DTOR_LIST__' / `__CTOR_LIST__

[Mateusz Mikuła]

> These are within an #ifndef HAVE_CTOR_LIST. During configure (of
> mingw-w64-crt), there's an "checking whether the linker provides
> __CTOR_LIST__... yes". If you're running into such an error, it sounds to
> me like this test didn't produce the expected result in your case. Can you
> have a look in the config.log why it didn't behave as expected?
>
> At this point, this check is only needed for compatibiltiy with LLD 7 and
> earlier (2 years ago). We could also conclude that it was early times for
> LLD's mingw compatibility and we could safely drop compatibility with it
> now.
>

AFAIK llvm-mingw and MSYS2 are the only projects using LLD + mingw-w64 so
IMO  it's reasonable.

___
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: Don't run TLS destructors for the main thread if exiting via _exit or ExitProcess

[Mateusz Mikuła]

>
> It can very well be the case that msys2's builds of libcxx are on top of
> libcxxabi even in the regular gcc based sysroots.
>

It totally is. Long time ago it was easier for me to make it work that way
and haven't changed it since.

___
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: Use Windows 10 as default _WIN32_WINNT value.

[Mateusz Mikuła]

MSYS2 already overrides default Windows version for mingw-w64 packages:
https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55

So no worries about the breakage here.

pon., 4 sty 2021 o 12:09 Mateusz Mikuła  napisał(a):

> MSYS2 already overrides default Windows version for mingw-w64 packages:
> https://github.com/msys2/MINGW-packages/blob/c416d59d2f373a6ab27d78dd29b6acd17e52c4d9/mingw-w64-headers-git/PKGBUILD#L55
>
> So no worries about the breakage here.
>
>
>
> *Od: *Martin Storsjö 
> *Wysłano: *czwartek, 31 grudnia 2020 21:32
> *Do: *Jacek Caban 
> *DW: *mingw-w64-public@lists.sourceforge.net
> *Temat: *Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as
> default _WIN32_WINNT value.
>
>
>
> On Thu, 31 Dec 2020, Jacek Caban wrote:
>
>
>
> > Yes, but the critical part is the very first sentence, which says that
> 'you
>
> > can specify which versions of Windows your code can run on.'. Note the
>
> > difference between *can* and *need*. When using mingw-w64 with its
> defaults,
>
> > you essentially *need* to do that if you're working on a modern
> application.
>
> > That article is about changing the value, not about the meaning of its
>
> > default value. The current difference between 'can' and 'need' comes
> from
>
> > toolchain defaults and all we need to do to be precisely compatible with
>
> > mentioned documentation is to change the default to win10, like authors
> of
>
> > this documentation did in their SDK.
>
>
>
> Fair enough, yes, that's a correct distinction to make here I guess.
>
>
>
> I guess that was the core part of my doubts regarding this, so with that
>
> cleared, I won't object to this change.
>
>
>
> I still think there's a risk that it'll break (or more subtly, affect) a
>
> handful of projects (I need to revisit VLC's configure, for instance), so
>
> some general headsup to e.g. the msys2 project probably is warranted
>
> though.
>
>
>
> >> Then again, I can agree with the argument that projects that are built
> for
>
> >> distribution across older versions maybe should take care to
> specifically
>
> >> set the define themselves anyway.
>
> >>
>
> >> Regarding the current archaic default, an alternative path (that
> doesn't
>
> >> take us all the way, but at least a bit on the way) would be to bump it
> to
>
> >> Win7.
>
> >
>
> >
>
> > I think that it's better than nothing, but it would only move the
> problem. It
>
> > also rises more questions like why not win8? When will we rise it again?
> Will
>
> > we wait until win7 becomes 19 years old? I think that those questions
> are
>
> > better answered individually by projects themselves, we can't make a
> single
>
> > choice good for all of them.
>
>
>
> That's true; the main motivation for specifically raising it to win7 would
>
> be if we'd generally drop support for older versions.
>
>
>
> >> I also faintly remember somebody suggesting that we'd formally drop
> support
>
> >> for XP altogether.
>
> >
>
> >
>
> > FWIW, that sounds about right to me, but I didn't want to make this
> change
>
> > about dropping XP support. I guess that what we're missing is some form
> of
>
> > discussion and formalizing it, if that's the consensus.
>
>
>
> Yeah, that's probably a separate discussion. And before doing it, I guess
>
> we should quantify what we actually gain from it, instead of just doing it
>
> for the sake of doing it. Being able to rely on more features in
>
> msvcrt.dll (for setups that use it) probably would be one thing.
>
>
>
> // Martin
>
>
>
>
>
>
>
> ___
>
> 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

Re: [Mingw-w64-public] Libraries present on Ubuntu but absent from Centos

[Mateusz Mikuła]

Fedora/RHEL/CentOS package mingw-w64 differently than Debian/Ubuntu.
Libraries you are asking for are located
in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/

Regards
Mateusz Mikuła

czw., 9 maj 2019, 05:01 użytkownik William Zeitler <
will...@williamzeitler.com> napisał:

> I have a mingw64 project I've been building successfully on Ubuntu 16/18
> for some time. But I need to migrate to Centos/Rhel 7.
>
> My project won't link on Centos due to "can't find various libraries".
> On Ubuntu, /usr/x86_64-w64-mingw32/lib has a long list of libraries
> (including the one's I'm missing on Centos) but on Centos this same
> folder contains no libraries at all.
>
> Libraries present on Ubuntu but missing on Centos include:
>
> libmsvcrt.dll.a
> libwinpthread.a
> msvcrt.dll.a
> libmsvcrt.a
> msvcrt.lib
> libmsvcrt.dll
> msvcrt.dll
> libmsvcrt.a
> libmsvcrt.dll.a
> msvcrt.dll.a
> ...
> and a host of others!
>
> Using 'rpm -qa | grep mingw64' on my Centos machine I have verified that
> the following packages are installed:
>
> mingw64-headers
> mingw64-filesystem
> mingw64-crt
> mingw64-binutils
> mingw64-winpthreads
> mingw64-gcc
> mingw64-gcc-c++
>
> Groveling Google has not proven helpful.
>
> I am grateful for your kind assistance,
>
> William Zeitler
>
>
>
>
>
>
>
> ___
> 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

Re: [Mingw-w64-public] msys2 / mingw32 targets 0x601 unexpectedly

[Mateusz Mikuła]

It's the mingw-w64-i686-headers-git package where it's defined. Generally
partial upgrades of MSYS2 are not supported but if you to be on your own
keep in mind crt, headers or winpthreads always have to be in the same
version.
MSYS2 had to bump WINNT because some package require Windows 7 features and
older Windows versions are EOL.

czw., 10 sty 2019 o 13:33 Tempelaar E. (Erik) 
napisał(a):

> I recently reconfigured a build environment for a mingw-built application
> but I ran into issues
> on Windows 10 caused by a #define _WIN32_WINNT in
> C:\msys64\mingw32\i686-w64-mingw32\include\_mingw.h
>
> In my installation it targets WINNT 0x0601
>
> #ifndef _WIN32_WINNT
> #define _WIN32_WINNT 0x601
> #endif
>
> My colleague's setup targets 0x0502.
>
> In my understanding 0x0502 is still the default:
> https://mingw-w64.org/doku.php/configure
>
> https://github.com/mirror/mingw-w64/blob/d72c4fe62568a216d52dca47ca8bace4e220d84f/mingw-w64-headers/configure.ac#L156
>
> I installed msys2-x86_64-20161025.exe and updated via pacman and installed
> i.e. base-devel and pacman -S mingw-w64-i686-gcc.
>
> How could I have ended up with 0x0601?
>
> What's the recommended way to control this and prevent issues like this?
>   Store an archive of msys2/mingw32 somewhere?
>   Add -D_WIN32_WINNT=0x0502 to our makefile?
>
> Here's a (subset) of possible updates for my colleague's setup, my guess
> is that the change is in one of these:
>
> mingw-w64-i686-ca-certificates 20170211-2 -> 20180409-1
> mingw-w64-i686-crt-git 6.0.0.5176.1fd1a585-1 -> 7.0.0.5285.7b2baaf8-1
> mingw-w64-i686-expat 2.2.5-1 -> 2.2.6-1
> mingw-w64-i686-gcc 7.3.0-2 -> 7.4.0-1
> mingw-w64-i686-gcc-libs 7.3.0-2 -> 7.4.0-1
> mingw-w64-i686-gdb 8.1-3 -> 8.2.1-1
> mingw-w64-i686-gettext 0.19.8.1-4 -> 0.19.8.1-7
> mingw-w64-i686-headers-git 6.0.0.5176.1fd1a585-1 -> 7.0.0.5285.7b2baaf8-1
> mingw-w64-i686-libwinpthread-git 6.0.0.5174.9726fb77-1 ->
> 7.0.0.5273.3e5acf5d-1
> mingw-w64-i686-ncurses 6.1.20180526-1 -> 6.1.20180908-1
> mingw-w64-i686-openssl 1.0.2.o-1 -> 1.1.1.a-1
> mingw-w64-i686-p11-kit 0.23.12-1 -> 0.23.14-1
> mingw-w64-i686-python3 3.7.0-10 -> 3.7.2-1
> mingw-w64-i686-sqlite3 3.24.0-1 -> 3.26.0-1
> mingw-w64-i686-tcl 8.6.8-1 -> 8.6.9-2
> mingw-w64-i686-tk 8.6.8-1 -> 8.6.9.1-1
> mingw-w64-i686-winpthreads-git 6.0.0.5174.9726fb77-1 ->
> 7.0.0.5273.3e5acf5d-1
> mingw-w64-i686-zlib 1.2.11-3 -> 1.2.11-5
>
> Please advise, I would like to know how this is supposed to work for
> msys2/mingw32
>
> Kind regards
>
>
>
>
>
> Disclaimer: This mail transmission and any attached files are confidential
> and are intended for the addressee only. If you are not the person or
> organization to whom it is addressed, you must not copy, disclose,
> distribute or take any action in reliance upon it. If you have received
> this message in error, please contact the sender by email and delete all
> copies of this message and all copies of any attached files.
>
> ___
> 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

Re: [Mingw-w64-public] [PATCH] Add _ftime aliases for all msvcr versions

[Mateusz Mikuła]

If you want to experiment mingw-build allows you to use trunk mingw-w64:
https://github.com/niXman/mingw-builds/blob/dba8a4ab94906afe677bf11199b6330e3e1ce8a2/build#L69
GCC 8.1.0 available at mingw-w64 sourceforge page was built from master
branch AFAIK.

Regards,
Mateusz Mikuła

śr., 2 sty 2019 o 20:27 Johannes Pfau  napisał(a):

> Am 02.01.19 um 18:02 schrieb Mateusz:
> > W dniu 02.01.2019 o 14:10, Johannes Pfau pisze:
> >> BTW: How do you handle branches for the patches? The attached patch
> >> is against the v6.x branch.
> > I didn't read this, sorry for noise in previous mail.
> >
> > The problem was solved in master branch by
> >
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/38496499910a580ddc449a7d09f3bc0302767f31/
> >
> > Regards,
> > Mateusz
>
> I guess I should have checked the master branch first, this is perfect.
> Any idea whether this will be backported to v6.x? OTOH I'll probably
> just post a patch to https://github.com/niXman/mingw-builds anyway, so
> it's not really urgent to have this in v6.x.
>
> Regards,
>
> Johannes
>
>
>
> ___
> 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

Re: [Mingw-w64-public] i686 gcc version 8.2?

[Mateusz Mikuła]

https://musl.cc works fine, check your DNS.

mingw-builds scripts and instructions are available in this repository:
https://github.com/niXman/mingw-builds/tree/develop

wt., 11 gru 2018 o 22:16 sisyphus  napisał(a):

> Hi,
>
> All of those https://musl.cc links are currently unreachable for me (with
> both Internet Explorer and Firefox).
> I'll try again later today.
>
> IMO, it's a great pity that the Win32/Personal Builds/mingw-builds
> directory is not updated more regularly.
>
> Where does one locate the instructions on how to build these compilers from
> source ?
>
> Cheers,
> Rob
>
> On Wed, Dec 12, 2018 at 2:13 AM Zach van Rijn  wrote:
>
> > On Tue, 2018-12-11 at 13:05 +, RK via Mingw-w64-public
> > wrote:
> > > Hi,
> > > Is it possible to access compiled versions of the i686 gcc
> > > version 8.2 toolchain? I can see version 7.4 via pacman and
> > > version 8.1 under the Toolchains targeting Win32/Personal
> > > Builds/mingw-builds directory.
> > > I would rather not build my own i686 toolchain.
> >
> > There are a few available at https://musl.cc/ --
> >
> > GCC_VER  = 8.2.0
> > BINUTILS_VER = 2.31.1
> > MUSL_VER = git-39ef612aa193cc6e954ac5a01574300ccd4b7ef9
> > GMP_VER  = 6.1.2
> > MPC_VER  = 1.1.0
> > MPFR_VER = 4.0.1
> > MINGW_VER= v6.0.0
> >
> >
> > https://musl.cc/i686-w64-mingw32-cross.tgz
> > https://musl.cc/i686-w64-mingw32-native.tgz
> > https://musl.cc/x86_64-w64-mingw32-cross.tgz
> > https://musl.cc/x86_64-w64-mingw32-native.tgz
> >
> > The '-cross' ones are intended to be run on x86_64 Linux, and
> > are fully static (no dependencies), and produce Win32 code.
> >
> > The '-native' ones can run on Windows (i686 and x86_64
> > respectively) but require one small extra step once they're
> > extracted: see Footnote #7 at https://musl.cc/#refs (To use
> > native MinGW32 toolchains, append ;E:\x86_64-w64-mingw32-
> > native\x86_64-w64-mingw32-native\bin (or similar) to %PATH%,
> > then copy ./include to ./TRIPLE/include)
> >
> > On my to-do list is to port all of the current Linux-targeted
> > toolchains to run on a Win32 host. But this takes time.
> >
> >
> > > Thanks!RK
> >
> > ZV
> >
> >
> >
> > ___
> > 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 mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Description of files in a mingw-w64 distribution

[Mateusz Mikuła]

There is https://github.com/niXman/mingw-builds/tree/develop

sob., 24 lis 2018 o 23:28 Edward Diener 
napisał(a):

> On 11/24/2018 5:18 PM, Earnie via Mingw-w64-public wrote:
> > On 11/24/2018 3:17 PM, Edward Diener wrote:
> >> Is there anywhere a description of the files in a mingw-w64
> >> distribution, with perhaps an explanation of whether any given file is
> >> used at compile, link, run-time, and/or for some other purpose ?
> >
> > What exactly are you trying to determine?  If a file is used at runtime
> > it will be in {usr,mingw32,mingw64}/bin directory.  If a file is
> > required for the build process you will find it in
> > {usr,mingw32,mingw64}/lib and perhaps under
> > {usr,mingw32,mingw64}/{i686,x86_64}-{pc,w64}-{msys,mingw32}/*
> directories.
>
> Yet there are many more directories in any given mingw-w64 distribution
> I have installed using the mingw-w64-install.exe program. What is the
> purpose of those other files if they are not being used at either
> compile, link, or run-time ? In other words why would a binary
> distribution of mingw-w64 have files that the end-user will never use ?
>
> >
> > You can use `pacman -Qo FILE` to determine which package a file is
> > related to.  You can then use `pacman -Qi PACKAGE` to get a description
> > of the package.  If a program is executable, usually add --help or
> > sometimes -h or perhaps -? will give a description of the executable
> > purpose and options.
> >
>
>
>
>
> ___
> 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

Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro

[Mateusz Mikuła]

Changelog for release and git version differ a lot and it won't apply
cleanly.
Your should get rid of Changelog part and it will work.


sob., 24 lis 2018 o 22:58 Edward Diener 
napisał(a):

> On 11/24/2018 1:21 AM, Liu Hao wrote:
> > 在 2018/11/24 13:30, Edward Diener 写道:
> >> ==> Starting prepare()...
> >> patch: invalid argument 'E:\\Programming\\VersionControl' for
> >> '$VERSION_CONTROL'
> >> Valid arguments are:
> >>- 'none', 'off'
> >>- 'simple', 'never'
> >>- 'existing', 'nil'
> >>- 'numbered', 't'
> >> ==> ERROR: A failure occurred in prepare().
> >>  Aborting...
> >>
> >> I do not know what I am doing wrong.
> >>
> > Probably you should `unset VERSION_CONTROL` before invoking
> > `makepkg-mingw`.
>
> OK, I got rid of the VERSION_CONTROL environment variable. Now my output
> is stopped with:
>
> ==> Starting prepare()...
> patching file configure
> Hunk #1 succeeded at 2956 with fuzz 1 (offset 91 lines).
> Hunk #2 succeeded at 2968 with fuzz 1 (offset 91 lines).
> patching file binutils/bucomm.c
> Hunk #1 succeeded at 590 with fuzz 2 (offset 15 lines).
> patching file binutils/elfedit.c
> patching file bfd/coff-alpha.c
> patching file bfd/coff-mips.c
> patching file bfd/coff-rs6000.c
> patching file bfd/coff-sh.c
> patching file bfd/coffcode.h
> patching file bfd/bfd-in.h
> Hunk #1 succeeded at 138 (offset 1 line).
> patching file bfd/bfd-in2.h
> Hunk #1 succeeded at 145 (offset 1 line).
> patching file binutils/dwarf.c
> Hunk #1 succeeded at 183 (offset 19 lines).
> patching file binutils/nm.c
> Hunk #1 succeeded at 171 (offset 1 line).
> Hunk #2 succeeded at 302 (offset 2 lines).
> patching file binutils/prdbg.c
> patching file binutils/readelf.c
> Hunk #1 succeeded at 1214 (offset 60 lines).
> Hunk #2 succeeded at 13255 (offset 883 lines).
> patching file binutils/strings.c
> Hunk #1 succeeded at 557 (offset -38 lines).
> Hunk #2 succeeded at 576 (offset -38 lines).
> Hunk #3 succeeded at 595 (offset -38 lines).
> patching file gas/as.h
> Hunk #1 succeeded at 437 (offset -1 lines).
> patching file gas/read.c
> Hunk #1 succeeded at 4437 (offset 22 lines).
> patching file gold/configure
> Hunk #1 succeeded at 7629 (offset 71 lines).
> patching file gold/configure.ac
> Hunk #1 succeeded at 655 (offset 20 lines).
> patching file include/ansidecl.h
> patching file ld/ChangeLog
> Hunk #1 succeeded at 1 with fuzz 1.
> patching file ld/ld.texinfo
> patching file ld/scripttempl/pe.sc
> patching file ld/scripttempl/pep.sc
> patching file ld/ChangeLog
> Hunk #1 FAILED at 1.
> 1 out of 1 hunk FAILED -- saving rejects to file ld/ChangeLog.rej
> patching file ld/scripttempl/pe.sc
> Hunk #1 succeeded at 159 (offset -2 lines).
> patching file ld/scripttempl/pep.sc
> Hunk #1 succeeded at 159 (offset -2 lines).
> ==> ERROR: A failure occurred in prepare().
>  Aborting...
>
> It looks like my patch is changing the ld/Changelog file in some way
> that is incorrect. The full patch was taken from
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d
> but it seems like the ChangeLog portion of the patch is somehow incorrect.
>
>
>
> ___
> 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

Re: [Mingw-w64-public] Why is inet_pton() not declared?

[Mateusz Mikuła]

Your example works fine with mingw-w64 6.0.0.

You can see function definition here:
https://gitlab.com/mati865/mingw-w64-mirror/blob/master/mingw-w64-headers/include/ws2tcpip.h#L444

śr., 21 lis 2018 o 22:49 Marc-André Lureau 
napisał(a):

> Hi
> On Thu, Nov 22, 2018 at 1:33 AM Earnie via Mingw-w64-public
>  wrote:
> >
> > On 11/21/2018 2:12 PM, Marc-André Lureau wrote:
> > > Hi,
> > >
> > > Apparently, this is a recurrent question on the web, but I can't find
> > > an answer what is the correct solution. From mingw git repo:
> > >
> > > commit 5fe3a72687f0629b68333fa438f4389db790651b
> > > Author: Rafaël Carré 
> > > Date:   Mon Mar 18 14:21:42 2013 +
> > >
> > >  Add InetPtonA, inet_pton, and InetPtonW prototypes.
> > >
> > > But inet_pton() is not declared in that commit (or later). Should it
> > > be declared in mingw headers or  some other way?
> > >
> >
> > You need to provide a short simple test case to show the issue.  Without
> > an example we can only guess what you might be doing wrong with this
> report.
> >
>
> On f29, with mingw64-headers-5.0.4-2.fc29.noarch
>
> $ x86_64-w64-mingw32-gcc test.c -lws2_32
>
> #include 
>
> int main(int argc, char *argv[])
> {
> void *foo = inet_ntop;
> return 0;
> }
>
>
> test.c:5:17: error: 'inet_ntop' undeclared (first use in this
> function); did you mean 'inet_ntoa'?
>
> (yet the program can link succesfully)
>
> > --
> > Earnie
> >
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> --
> Marc-André Lureau
>
>
> ___
> 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

Re: [Mingw-w64-public] [PATCH] _mingw.h.in: Improve clang support.

[Mateusz Mikuła]

I think it's upstream clang bug reported here:
https://github.com/Alexpux/MINGW-packages/issues/1677#issuecomment-394906508

wt., 26 cze 2018 o 13:57 Liu Hao  napisał(a):

> 在 2018/6/26 19:33, Jacek Caban 写道:
> > I did tests with c89 and c99 before submitting the patch (C++ is
> > irrelevant, I don't change behaviour there). I'm also able to build
> > Firefox with this patch (which in the past revealed a few inline
> > problems, so that's a nice test). Is there anything in particular that
> > you think we should test?
> >
> > Thanks,
> > Jacek
> >
>
> Does compiling and linking the attached two files using the following
> command result in multiple definition ?
>
> clang a.c b.c -std=c99
>
> If we were defining `__forceinline` that way and compiling using GCC
> this would result in multiple definitions of `ctime_r()`.
>
>
> --
> 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] headers: Complete the winnt.h structs/defines for ARM64

[Mateusz Mikuła]

There is a bug reported for this commit:
https://sourceforge.net/p/mingw-w64/bugs/736/

pon., 19 mar 2018 o 07:30 Martin Storsjö  napisał(a):

> On Mon, 19 Mar 2018, Liu Hao wrote:
>
> > 在 03/19/2018 03:12 AM, Martin Storsjö 写道:
> >> Sync the latest version from wine.
> >>
> >> Signed-off-by: Martin Storsjö 
> >> ---
> >>  mingw-w64-headers/include/winnt.h | 119
> ++
> >>  1 file changed, 108 insertions(+), 11 deletions(-)
> >>
> >>
> >
> >
> > This patch looks good to me.
>
> Thanks, pushed.
>
> // 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] mingw-w64 and clang C++ ABI compatibility

[Mateusz Mikuła]

Those are Clang bugs [0].

Multiple definitions error has been fixed in [1] and probably (just
guessing) made it to Clang 6.0.0 release.

Undefined references bug happens when you link code compiled by Clang to
static libstdc++ (and probably other static libs too) compiled by GCC. I
think there is still no solution for this one.

[0] https://lists.llvm.org/pipermail/cfe-dev/2017-April/053530.html
[1] https://reviews.llvm.org/D33620

śr., 2 maj 2018 o 18:16 Sukhbir Singh  napisał(a):

> Hi,
>
> I have a question about C++ ABI compatibility (or lack thereof) between
> mingw-w64 and clang.
>
> I am trying to cross-compile go-webrtc
> [https://github.com/keroserene/go-webrtc] with mingw-w64 (cgo), which has
> webrtc as its dependency (compiled with clang). I am running into errors
> during the linking stage:
>
> /var/tmp/dist/mingw-w64/x86_64-w64-mingw32/include/malloc.h:183:0:
> note: this is the location of the previous definition
>  #define alloca(x) __builtin_alloca((x))
>  ^
> # github.com/keroserene/go-webrtc
>
> /var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/../lib/libstdc++.a(cow-stdexcept.o):
> In function `std::string::_M_data() const':
>
> /var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:44:
> multiple definition of `std::logic_error::logic_error(std::logic_error
> const&)'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/peerconnection.cc.o:peerconnection.cc:(.text$_ZNSt11logic_errorC2ERKS_[_ZNSt11logic_errorC2ERKS_]+0x0)
> :
> first defined here
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x5a9):
> undefined reference to `cricket::AudioCodec::ToString() const'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x6de):
> undefined reference to `webrtc::RtpExtension::ToString() const'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x813):
> undefined reference to `cricket::DataCodec::ToString() const'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x8f5):
> undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x96a):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xa1b):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xbf8):
> undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xc6d):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xd20):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xdb1):
> undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xe26):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xed5):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xf6d):
> undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0xfe2):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x1094):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x112c):
> undefined reference to `rtc::FatalMessage::FatalMessage(char const*, int)'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x11a1):
> undefined reference to `rtc::FatalMessage::~FatalMessage()'
> /tmp/go-build868110800/
> github.com/keroserene/go-webrtc/_obj/ctestenums.cc.o:ctestenums.cc:(.text+0x1254):
> undefined referen

Re: [Mingw-w64-public] GCC Fallthrough warnings.

[Mateusz Mikuła]

There is no patch attached.

2018-03-10 0:32 GMT+01:00 :

> When compiling with GCC 7.3.0, I got warnings about falltrhoughts and I mad
> e patch for this that I'm attaching to this E-Mail.
>
> 
> --
> 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

[Mingw-w64-public] __MINGW_GNUC_PREREQ vs clang

[Mateusz Mikuła]

Clang defines itself as GCC 4.2.1 which can cause issues like multiple
definitions of `__m64`, `__m128`, ... coming from crt/intrin.h when
`-march=i686` is used when building compiler-rt.
When I override it for clang to return false compiler-rt builds fine with
`-march=i686`.

I think it's a good idea to stop treating clang like few years outdated gcc
version.
Any thoughts?
--
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

[Mateusz Mikuła]

You can try linking to different version of runtime library [0] like MSVC
does by default.

[0]
https://stackoverflow.com/questions/3402252/how-to-link-against-msvcr90-dll-with-mingw-gcc

2017-10-19 10:54 GMT+02:00 Etienne Sandré-Chardonnal :

> Hi,
>
> I don't think this is a text/binary issue:
>  - I'm already opening with "rb"
>  - This is random
>  - This only happens when doing concurrent reads
>  - ftell works while _ftelli64 has problems
>
> To me this is a race condition in _ftelli64
>
> I have tested the code in MSVC 2015, and the bug is not there.
>
> Etienne
>
> 2017-10-19 10:36 GMT+02:00 Kai Tietz via Mingw-w64-public <
> mingw-w64-public@lists.sourceforge.net>:
>
> > 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 <
> > etienne.san...@m4x.org>:
> > > 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
> >
> 
> --
> 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] Default _WIN32_WINNT version too low?

[Mateusz Mikuła]

The discussion is about master branch.

2017-10-16 4:53 GMT+02:00 Jean-Baptiste Kempf :

> Hello,
>
> Could we keep XP for the 5.0 release and then drop it after?
>
> For VLC, we will keep XP compatibility for the next major release, in a
> few days, and then drop it totally.
>
> On Sun, 15 Oct 2017, at 11:21, Martell Malone wrote:
> > I figured this would be a good point to revive this discussion.
> > LLVM/Clang progress for mingw-w64 has come on quite a lot since I brought
> > this up.
> >
> > The last time we had an issue around libcxx needing 0x600 for c++ threads
> > without winpthreads.
> > Now libunwind is in the same situation.
> >
> > Martin has been working hard to get libunwind in shape for mingw-w64 but
> > the locks also require 0x600.
> > (This is the same api used in libc++)
> > https://reviews.llvm.org/D38704
> >
> > I thought FF 52 was the last version but
> > https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista
> >
> > Also it seems to be well past that time now anyway.
> > https://www.mozilla.org/media/img/firefox/organizations/
> release-overview-high-res.78cf477dd915.png
> >
> >
> > A little longer term
> > I think with this transition we should also be able to create a new
> > pthreads library using the same api's available after vista.
> > This should give us room to have c11 threads and just wrap pthreads
> > around
> > this much like musl libc does.
> >
> >
> > On Mon, Jun 12, 2017 at 7:18 PM, Adrien Nader  wrote:
> >
> > > Hi,
> > >
> > > The implication of this change would be that you need a separate
> > > toolchain to target these OSes and 5.x is not going to be abandoned
> > > tomorrow, which gives you plenty of time.
> > >
> > > I've followed the support from browsers and FF 53 which is an ESR is
> the
> > > last browser to support XP. Since it's recent and ESR, support will
> last
> > > a few more months but that's about it.
> > >
> > > The possibility for you would be the aforementioned patch and default
> to
> > > something more recent to XP but still allow to target it. That's the
> > > moment you're welcome to do it and post it for review on the list.
> > > Targeting XP will not be supported but that's actually the current
> > > situation anyway since the majority of people here are not testing XP
> > > anymore.
> > >
> > > --
> > > Adrien Nader
> > >
> > > 
> > > --
> > > 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
>
>
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
>
> 
> --
> 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 casts in ua_wcs*chr in stralign.h

[Mateusz Mikuła]

 No problem, it was left forgotten there.

Yes I was making clang able to host itself at MSYS2 and ran into this
error on 64bit builds. If Lio says C-style cast is fine then I'm OK with
that.

I'm 80% sure I've seen this in another project as well and GCC allowed
it but your description is better and this patch should be committed.
You can add my sign-off if you want but it's not important.


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] headers: Add casts in ua_wcs*chr
in stralign.h
Date: Fri, 25 Aug 2017 14:23:09 +0300 (EEST)
To: Mingw-w64-public
From: Martin Storsjö
> On Fri, 25 Aug 2017, Mateusz Mikuła wrote:
>
>> There was discussion if this should be done via cast or union, both
>> versions were attached at some point of [1] discussion.
>>
>> [1] https://sourceforge.net/p/mingw-w64/mailman/message/35923114/
>
> Oh, I see - sorry for missing that.
>
> I don't mind whichever approach gets chosen; using a union is totally
> ok with me, as long as some sort of fix is committed.
>
> FWIW, I take it you ran into this issue in trying to build libcxx as
> well? It might be good to amend your patch with my explanation - it's
> not a matter about gcc vs clang (g++ also refuses to convert from
> const wchar_t* to wchar_t*), but this is only an issue if the libcxx
> headers get included inbetween, where the const wchar_t* prototype
> comes from.
>
> // 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



signature.asc
Description: OpenPGP digital signature
--
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 casts in ua_wcs*chr in stralign.h

[Mateusz Mikuła]

There was discussion if this should be done via cast or union, both
versions were attached at some point of [1] discussion.

[1] https://sourceforge.net/p/mingw-w64/mailman/message/35923114/

2017-08-25 11:12 GMT+02:00 Martin Storsjö :

> When building libcxx, a version of wcschr that returns const
> is provided, breaking compilation here since the return from
> wcschr is returned directly as if it were a const pointer.
> By adding these casts, compilation succeeds.
>
> This matches the calls to uaw_wcschr and uaw_wcsrchr directly
> below, having similar casts.
>
> Signed-off-by: Martin Storsjö 
> ---
>  mingw-w64-headers/include/stralign.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mingw-w64-headers/include/stralign.h
> b/mingw-w64-headers/include/stralign.h
> index 9b5637d..f4d9d6d 100644
> --- a/mingw-w64-headers/include/stralign.h
> +++ b/mingw-w64-headers/include/stralign.h
> @@ -118,11 +118,11 @@ extern "C" {
>
>  #ifndef __CRT__NO_INLINE
>__CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
> -if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
> +if(WSTR_ALIGNED(String)) return (PUWSTR_C)wcschr((PCWSTR)
> String,Character);
>  return (PUWSTR_C)uaw_wcschr(String,Character);
>}
>__CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
> -if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
> +if(WSTR_ALIGNED(String)) return (PUWSTR_C)wcsrchr((PCWSTR)
> String,Character);
>  return (PUWSTR_C)uaw_wcsrchr(String,Character);
>}
>  #if defined(__cplusplus) && defined(_WConst_Return)
> --
> 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] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

Ping

On Sat, 2017-06-04 at 15∶31 +0200, Mateusz Mikuła wrote:
> 
> 
>   I sent  patch casting to PUWSTR_C half hour after first message
> when I noticed how stupid it was before.
> 
>   
> 
> Should still apply cleanly (attachment has wrong name):
> https://sourceforge.net/p/mingw-w64/mailman/message/35770400/
> 
> 
> 
> 
> 
> -- Original Message --
> 
>   Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast
> ua_wcschr
>   and ua_wcsrchr returns to wchar_t *
> 
>   Date: Sun, 04 Jun 2017 12:40:05 +
> 
>   To: Mingw-w64-public
> 
>   From: Norbert Pfeiler
> 
> >   1st point was to use PUWSTR_C instead of wchar_t * for the
> > cast, still
> > stands.
> > 2nd point was to »to avoid further warnings« and i would like to –
> > once
> > again – vote to avoid union casts.
> > 
> > As far as i know there is no reason to believe that -Wcast-qual (as
> > well as
> > -Wsystem-headers) will be a default warning anytime soon. And even
> > then it
> > would be just a warning but still standards-conforming code (which
> > is also
> > a reason for it not to become a default warning).
> > 
> > A C-style cast is perfectly appropriate here, no union needed.
> > 
> > FTR, it’s not only Clang which doesn’t accept the pre-patch code,
> > GCC
> > errors too.
> > 
> > Best, Norbert.
> > 
> > On Sun, Jun 4, 2017 at 12:18 PM Mateusz Mikuła 
> > wrote:
> > 
> > 
> >   
> > > Anything to improve?
> > > 
> > > From 05bc4cbc93f5f9942fc28a578dc1afa68d69daa2 Mon Sep 17 00:00:00
> > > 2001
> > > From: Mateusz Mikula 
> > > Date: Sun, 4 Jun 2017 11:33:22 +0200
> > > Subject: [PATCH] cast ua_wcschr and ua_wcsrchr returns when
> > > WSTR_ALIGNED is
> > >  true
> > > 
> > > Clang doesn't allow implicit conversion form "const wchar_t *" to
> > > "PUWSTR_C" (aka wchar_t *)
> > > 
> > > Signed-off-by: Mateusz Mikula 
> > > ---
> > >  mingw-w64-headers/include/stralign.h | 15 +--
> > >  1 file changed, 13 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/mingw-w64-headers/include/stralign.h
> > > b/mingw-w64-headers/include/stralign.h
> > > index 9b5637d6..4b157c27 100644
> > > --- a/mingw-w64-headers/include/stralign.h
> > > +++ b/mingw-w64-headers/include/stralign.h
> > > @@ -117,12 +117,23 @@ extern "C" {
> > >size_t ua_wcslen(PCUWSTR String);
> > > 
> > >  #ifndef __CRT__NO_INLINE
> > > +union {
> > > +  wchar_t *wcharPointer;
> > > +  const wchar_t *constWcharPointer;
> > > +} cast;
> > > +
> > >__CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR
> > > Character) {
> > > -if(WSTR_ALIGNED(String)) return
> > > wcschr((PCWSTR)String,Character);
> > > +if(WSTR_ALIGNED(String)) {
> > > +  cast.constWcharPointer = wcschr((PCWSTR)String,Character);
> > > +  return cast.wcharPointer;
> > > +}
> > >  return (PUWSTR_C)uaw_wcschr(String,Character);
> > >}
> > >__CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR
> > > Character) {
> > > -if(WSTR_ALIGNED(String)) return
> > > wcsrchr((PCWSTR)String,Character);
> > > +if(WSTR_ALIGNED(String)) {
> > > +  cast.constWcharPointer =
> > > wcsrchr((PCWSTR)String,Character);
> > > +  return cast.wcharPointer;
> > > +}
> > >  return (PUWSTR_C)uaw_wcsrchr(String,Character);
> > >}
> > >  #if defined(__cplusplus) && defined(_WConst_Return)
> > > --
> > > 2.12.1
> > > 
> > > 
> > > 
> > > -- Original Message --
> > > Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr
> > > and
> > > ua_wcsrchr returns to wchar_t *
> > > Date: Thu, 6 Apr 2017 11:48:24 +0200
> > > To: Mingw-w64-public
> > > From: Kai Tietz
> > > 
> > > 
> > > >   A cast via union looks like this:
> > > > type1 *foo(const type1 *my_const_ptr)
> > > > {
> > > > union {
> > > >   type1 *t1;
> > > >   const type1 *ct1;
> > > > } v;
> > > > v.ct1 = my_const_ptr;
> > > > return v.t1;
> > > > }
> > > > 
&

Re: [Mingw-w64-public] [PATCH] remove cast to int from mantissa for __mingw_printf

[Mateusz Mikuła]

All patches for mingw-64 should be signed off.


-- Original Message --
Subject: [Mingw-w64-public] [PATCH] remove cast to int from mantissa for
__mingw_printf
Date: Mon, 12 Jun 2017 16:24:17 +0100
To: Mingw-w64-public
From: Martell Malone
> In this thread https://sourceforge.net/p/mingw-w64/bugs/459/
> there is a suggested fix for print with whole numbers
>
> The builtin __mingw_printf is inconsistent with printf on %a format.
>> I think __mingw_printf is wrong, because obviously 1.0 != 0x0p-63.
>
> vacaboja opened an issue on msys2 for this
> https://github.com/msys2/msys2/issues/35
> and suggested a fix of removing the case to int
> here is a patch that does just that.
>
> Please Review
>
> diff --git a/mingw-w64-crt/stdio/mingw_pformat.c
> b/mingw-w64-crt/stdio/mingw_pformat.c
> index 445320c0..3c7f0833 100644
> --- a/mingw-w64-crt/stdio/mingw_pformat.c
> +++ b/mingw-w64-crt/stdio/mingw_pformat.c
> @@ -2113,7 +2113,7 @@ void __pformat_emit_xfloat( __pformat_fpreg_t value,
> __pformat_t *stream )
>  /* taking the rightmost digit in each pass...
>   */
>  int c = value.__pformat_fpreg_mantissa & 0xF;
> -if( c == (int) value.__pformat_fpreg_mantissa)
> +if( c == value.__pformat_fpreg_mantissa)
>  {
>/* inserting the radix point, when we reach the last,
> * (i.e. the most significant digit), unless we found no
> --
> 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



signature.asc
Description: OpenPGP digital signature
--
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

[Mateusz Mikuła]

> However, once I try to use some more c++ features, I get the
> following
> error, and it seems to be associated with the compiled object files
> themselves:
> 
> "invalid or corrupt file: no symbol for COMDAT section ..." (and a
> hex
> address).

It's not possible to mix static libstdc++ with Microsoft C++ runtime.
In fact even mingw-w64 based Clang doesn't play nicely with static
libstdc++ http://lists.llvm.org/pipermail/cfe-dev/2017-April/053530.htm
l

signature.asc
Description: This is a digitally signed message part
--
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] [HELP] Need to emulate _get_current_locale

[Mateusz Mikuła]

On Windows 10 it is builtin in msvcrt.dll:

$ winedump -j export '/media/mateusz/C/Windows/System32/msvcrt.dll' |
grep locale
  00028CB0   227 _create_locale
  00029000   308 _free_locale
  000290C0   336 _get_current_locale
  0002E710  1004 _wsetlocale
  0002F5D0  1153 localeconv
  00029970  1203 setlocale

Full dump https://paste.ubuntu.com/24782002/

Dnia 2017-06-04, nie o godzinie 01:19 +0100, Martell Malone pisze:
> Hi,
> 
> I am currently looking at emulating
> _locale_t _get_current_locale(void);
> 
> We were previously hacking around this by just returning 0 cast as
> _locale_t in msys2
> This is obviously incorrect and any sane c++ tries to check multiple
> times
> with that result.
> 
> What would be the correct way to emulate this in mingw-w64 without
> affecting or clashing with the internal windows value
> Can we do a wrapper that tries to check the real value on windows and
> if
> that doesn't work return a default value?
> 
> Jacek do you have any insight here?
> 
> Best,
> Martell
> ---
> ---
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

signature.asc
Description: This is a digitally signed message part
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

I sent  patch casting to PUWSTR_C half hour after first message when I
noticed how stupid it was before.

Should still apply cleanly (attachment has wrong name):
https://sourceforge.net/p/mingw-w64/mailman/message/35770400/


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
ua_wcsrchr returns to wchar_t *
Date: Sun, 04 Jun 2017 12:40:05 +
To: Mingw-w64-public
From: Norbert Pfeiler
> 1st point was to use PUWSTR_C instead of wchar_t * for the cast, still
> stands.
> 2nd point was to »to avoid further warnings« and i would like to – once
> again – vote to avoid union casts.
>
> As far as i know there is no reason to believe that -Wcast-qual (as well as
> -Wsystem-headers) will be a default warning anytime soon. And even then it
> would be just a warning but still standards-conforming code (which is also
> a reason for it not to become a default warning).
>
> A C-style cast is perfectly appropriate here, no union needed.
>
> FTR, it’s not only Clang which doesn’t accept the pre-patch code, GCC
> errors too.
>
> Best, Norbert.
>
> On Sun, Jun 4, 2017 at 12:18 PM Mateusz Mikuła  wrote:
>
>> Anything to improve?
>>
>> From 05bc4cbc93f5f9942fc28a578dc1afa68d69daa2 Mon Sep 17 00:00:00 2001
>> From: Mateusz Mikula 
>> Date: Sun, 4 Jun 2017 11:33:22 +0200
>> Subject: [PATCH] cast ua_wcschr and ua_wcsrchr returns when WSTR_ALIGNED is
>>  true
>>
>> Clang doesn't allow implicit conversion form "const wchar_t *" to
>> "PUWSTR_C" (aka wchar_t *)
>>
>> Signed-off-by: Mateusz Mikula 
>> ---
>>  mingw-w64-headers/include/stralign.h | 15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/mingw-w64-headers/include/stralign.h
>> b/mingw-w64-headers/include/stralign.h
>> index 9b5637d6..4b157c27 100644
>> --- a/mingw-w64-headers/include/stralign.h
>> +++ b/mingw-w64-headers/include/stralign.h
>> @@ -117,12 +117,23 @@ extern "C" {
>>size_t ua_wcslen(PCUWSTR String);
>>
>>  #ifndef __CRT__NO_INLINE
>> +union {
>> +  wchar_t *wcharPointer;
>> +  const wchar_t *constWcharPointer;
>> +} cast;
>> +
>>__CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
>> -if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
>> +if(WSTR_ALIGNED(String)) {
>> +  cast.constWcharPointer = wcschr((PCWSTR)String,Character);
>> +  return cast.wcharPointer;
>> +}
>>  return (PUWSTR_C)uaw_wcschr(String,Character);
>>}
>>__CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
>> -if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
>> +if(WSTR_ALIGNED(String)) {
>> +  cast.constWcharPointer = wcsrchr((PCWSTR)String,Character);
>> +  return cast.wcharPointer;
>> +}
>>  return (PUWSTR_C)uaw_wcsrchr(String,Character);
>>}
>>  #if defined(__cplusplus) && defined(_WConst_Return)
>> --
>> 2.12.1
>>
>>
>>
>> -- Original Message --
>> Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
>> ua_wcsrchr returns to wchar_t *
>> Date: Thu, 6 Apr 2017 11:48:24 +0200
>> To: Mingw-w64-public
>> From: Kai Tietz
>>> A cast via union looks like this:
>>> type1 *foo(const type1 *my_const_ptr)
>>> {
>>> union {
>>>   type1 *t1;
>>>   const type1 *ct1;
>>> } v;
>>> v.ct1 = my_const_ptr;
>>> return v.t1;
>>> }
>>>
>>> The advantage of such a pattern is that no type conversion
>>> errors/warnings are shown.  So for casting from const to none-const,
>>> this variant is to be preferred.  (and it works for C, and C++!!!)
>>>
>>> Cheers,
>>> Kai
>>>
>>> 2017-04-05 15:51 GMT+02:00 Mateusz Mikuła :
>>>>> Hmm, using here "wchar_t *" as cast looks wrong.  Actually we should
>>>>> use anyway PUWSTR_C instead.
>>>> I noticed it a bit too late and sent another patch casting to PUWSTR_C.
>>>>> Nevertheless we can have here a const/none-const conversion (means
>>>>> const specifiers for C-runtime function isn't regarded right?).  I
>>>>> would suggest to introduce a union-cast instead to avoid further
>>>>> warnings instead.
>>>> Conversion from const pointer to normal pointer is definitely unsafe but
>>>> that's probably what GCC just did.
>>>> I'm unsure what you mean by "un

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

Anything to improve?

From 05bc4cbc93f5f9942fc28a578dc1afa68d69daa2 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula 
Date: Sun, 4 Jun 2017 11:33:22 +0200
Subject: [PATCH] cast ua_wcschr and ua_wcsrchr returns when WSTR_ALIGNED is
 true

Clang doesn't allow implicit conversion form "const wchar_t *" to
"PUWSTR_C" (aka wchar_t *)

Signed-off-by: Mateusz Mikula 
---
 mingw-w64-headers/include/stralign.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/include/stralign.h
b/mingw-w64-headers/include/stralign.h
index 9b5637d6..4b157c27 100644
--- a/mingw-w64-headers/include/stralign.h
+++ b/mingw-w64-headers/include/stralign.h
@@ -117,12 +117,23 @@ extern "C" {
   size_t ua_wcslen(PCUWSTR String);
 
 #ifndef __CRT__NO_INLINE
+union {
+  wchar_t *wcharPointer;
+  const wchar_t *constWcharPointer;
+} cast;
+   
   __CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
+if(WSTR_ALIGNED(String)) {
+  cast.constWcharPointer = wcschr((PCWSTR)String,Character);
+  return cast.wcharPointer;
+}
 return (PUWSTR_C)uaw_wcschr(String,Character);
   }
   __CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
+if(WSTR_ALIGNED(String)) {
+  cast.constWcharPointer = wcsrchr((PCWSTR)String,Character);
+  return cast.wcharPointer;
+}
 return (PUWSTR_C)uaw_wcsrchr(String,Character);
   }
 #if defined(__cplusplus) && defined(_WConst_Return)
-- 
2.12.1



-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
ua_wcsrchr returns to wchar_t *
Date: Thu, 6 Apr 2017 11:48:24 +0200
To: Mingw-w64-public
From: Kai Tietz
> A cast via union looks like this:
> type1 *foo(const type1 *my_const_ptr)
> {
> union {
>   type1 *t1;
>   const type1 *ct1;
> } v;
> v.ct1 = my_const_ptr;
> return v.t1;
> }
>
> The advantage of such a pattern is that no type conversion
> errors/warnings are shown.  So for casting from const to none-const,
> this variant is to be preferred.  (and it works for C, and C++!!!)
>
> Cheers,
> Kai
>
> 2017-04-05 15:51 GMT+02:00 Mateusz Mikuła :
>>> Hmm, using here "wchar_t *" as cast looks wrong.  Actually we should
>>> use anyway PUWSTR_C instead.
>> I noticed it a bit too late and sent another patch casting to PUWSTR_C.
>>> Nevertheless we can have here a const/none-const conversion (means
>>> const specifiers for C-runtime function isn't regarded right?).  I
>>> would suggest to introduce a union-cast instead to avoid further
>>> warnings instead.
>> Conversion from const pointer to normal pointer is definitely unsafe but
>> that's probably what GCC just did.
>> I'm unsure what you mean by "union-cast" but you can commit your fix.
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

From 05bc4cbc93f5f9942fc28a578dc1afa68d69daa2 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula 
Date: Sun, 4 Jun 2017 11:33:22 +0200
Subject: [PATCH] cast ua_wcschr and ua_wcsrchr returns when WSTR_ALIGNED is
 true

Clang doesn't allow implicit conversion form "const wchar_t *" to "PUWSTR_C" 
(aka wchar_t *)

Signed-off-by: Mateusz Mikula 
---
 mingw-w64-headers/include/stralign.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/include/stralign.h 
b/mingw-w64-headers/include/stralign.h
index 9b5637d6..4b157c27 100644
--- a/mingw-w64-headers/include/stralign.h
+++ b/mingw-w64-headers/include/stralign.h
@@ -117,12 +117,23 @@ extern "C" {
   size_t ua_wcslen(PCUWSTR String);
 
 #ifndef __CRT__NO_INLINE
+union {
+  wchar_t *wcharPointer;
+  const wchar_t *constWcharPointer;
+} cast;
+
   __CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) ret

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

[Mateusz Mikuła]

 0x0502 is Windows Server 2003

If changing default target it should be done properly. Windows Vista is
EOL and it's share is lower than XP so I'd vote for Windows 7.


-- Original Message --
Subject: [Mingw-w64-public] Default _WIN32_WINNT version too low?
Date: Sat, 3 Jun 2017 18:27:40 +0100
To: Mingw-w64-public
From: Martell Malone
> Hey,
>
> As per my discussion with LLVM devs here.
> 0x600 is the min version required to support libc++ win32 threading.
> https://reviews.llvm.org/D33384
>
> I'm not quite sure why we currently have 0x502 as the default.
> It seems to be a number sitting between Windows XP and Vista.
> I would like to propose we bump to 0x600 which is Vista for this reason.
>
> Kind Regards
> Martell
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



signature.asc
Description: OpenPGP digital signature
--
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++ cout executable size

[Mateusz Mikuła]

Pasted wrong link, here is fixed 
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/ios_base.h#L601

On June 3, 2017 10:11:30 AM GMT+02:00, "Mateusz Mikuła"  
wrote:
>Here is ios_base::Init
>https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/iostream#L74
>If you really want to understand what compiler put into your executable
>you have to disassemble it.
>Bear in mind that even if you knew whole source code of libstdc++ you
>would get different code in binary due to compiler optimizations and
>disabling them for final product is stupid unless they break something.
>
>On June 3, 2017 8:35:43 AM GMT+02:00, bob by 
>wrote:
>>2017-06-03 5:26 GMT+04:00 Liu Hao :
>>
>>> On 2017/6/3 0:18, bob by wrote:
>>>
>>>> Can't find the code of std::ios_base::Init
>>>>
>>>> It should be somewhere in here, but I can't find it:
>>>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/libstdc++/api/a00801.html
>>>>
>>>> Why do you want to find its source? It is merely the answer to your
>>> previous question: `#include ` will make your executable
>>larger,
>>> although you seem not using anything in that header,. And jon_y is
>>right
>>> for the reason.
>>
>>
>>I want to understand what runtime is doing. I don't want the code I
>>can't
>>understand to be in my exe, it makes me feel like I don't understand
>>the
>>program I myself wrote.
>>--
>>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] C++ cout executable size

[Mateusz Mikuła]

Here is ios_base::Init 
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/iostream#L74
If you really want to understand what compiler put into your executable you 
have to disassemble it.
Bear in mind that even if you knew whole source code of libstdc++ you would get 
different code in binary due to compiler optimizations and disabling them for 
final product is stupid unless they break something.

On June 3, 2017 8:35:43 AM GMT+02:00, bob by  wrote:
>2017-06-03 5:26 GMT+04:00 Liu Hao :
>
>> On 2017/6/3 0:18, bob by wrote:
>>
>>> Can't find the code of std::ios_base::Init
>>>
>>> It should be somewhere in here, but I can't find it:
>>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/libstdc++/api/a00801.html
>>>
>>> Why do you want to find its source? It is merely the answer to your
>> previous question: `#include ` will make your executable
>larger,
>> although you seem not using anything in that header,. And jon_y is
>right
>> for the reason.
>
>
>I want to understand what runtime is doing. I don't want the code I
>can't
>understand to be in my exe, it makes me feel like I don't understand
>the
>program I myself wrote.
>--
>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] Add flag for symlink creation by unprivileged users

[Mateusz Mikuła]

Are you sure 0x3 value (0x1 | 0x2) is valid for
VALID_SYMBOLIC_LINK_FLAGS on every OS from 7 to 10?

Dnia 2017-05-27, sob o godzinie 11:14 +, Samuel Leslie pisze:
> The MSDN documentation doesn't appear to have been updated yet:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363866(v=v
> s.85).aspx
> 
> But you can find the details on the official developer blog:
> https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10
> /
> 
> Signed-off-by: Samuel D. Leslie 
> ---
>  mingw-w64-headers/include/winbase.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mingw-w64-headers/include/winbase.h b/mingw-w64-
> headers/include/winbase.h
> index 7e12bcbd..dd3a1b46 100644
> --- a/mingw-w64-headers/include/winbase.h
> +++ b/mingw-w64-headers/include/winbase.h
> @@ -2872,8 +2872,9 @@ extern "C" {
>  #if _WIN32_WINNT >= 0x0600
>  
>  #define SYMBOLIC_LINK_FLAG_DIRECTORY (0x1)
> +#define SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (0x2)
>  
> -#define VALID_SYMBOLIC_LINK_FLAGS SYMBOLIC_LINK_FLAG_DIRECTORY
> +#define VALID_SYMBOLIC_LINK_FLAGS (SYMBOLIC_LINK_FLAG_DIRECTORY |
> SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE)
>  
>    WINBASEAPI BOOLEAN APIENTRY CreateSymbolicLinkA (LPCSTR
> lpSymlinkFileName, LPCSTR lpTargetFileName, DWORD dwFlags);
>    WINBASEAPI BOOLEAN APIENTRY CreateSymbolicLinkW (LPCWSTR
> lpSymlinkFileName, LPCWSTR lpTargetFileName, DWORD dwFlags);
> --
> ---
> ---
> 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

signature.asc
Description: This is a digitally signed message part
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c

[Mateusz Mikuła]

Symbols in libuuid.a are definitely duplicated, tested on MSYS2, Ubuntu,
Arch:

nm '/usr/x86_64-w64-mingw32/lib/libuuid.a' | grep FileProtocol
 R CLSID_FileProtocol
 r .rdata$CLSID_FileProtocol
00f0 R CLSID_FileProtocol

Here is disassembly of first duplicated symbol from Ubuntu:
https://paste.ubuntu.com/24493619/


2017-05-01 18:03 GMT+02:00 Liu Hao :

> On 2017/5/1 21:27, Tomay wrote:
> > The following UUIDs are defined in both *uuid.c* and *extra-uuid.c*
> source
> > files, whitch leads to linking errors with duplicate symbols when using
> > *libuuid.a*
> >
> In my opinion it is practically incorrect, but you shouldn't get linker
> errors because the macro `INITGUID` is defined in both files hence each
> GUID definition is marked with the `selectany` attribute (see definition
> of the macro `DEFINE_GUID` in [guiddef.h]).
>
> --
> Best regards,
> LH_Mouse
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

 I tested these _out of box_ cases:

No patch:
GCC: silent|Clang: 32bit silent, 64bit error

Cast to "PUWSTR_C":
GCC: silent|Clang: silent

Union cast:
GCC: silent|Clang: silent

If you want to use Union cast You should create fix because I have no
idea about MinGW-w64 coding standards in case like this.
Testing this is very tricky since I could reproduce it only when
building 64bit libc++ but to get to this stage enormous amount of hacks
have been created (workaround missing mingw-w64 defines, wrong code for
mingw, etc.)
Basically both compilers tell it comes from "#include" from
few cpp files:

|In file included from
D:/projekty/msys2/MINGW-packages/mingw-w64-clang/src/llvm-3.9.0.src/projects/libcxx/src/chrono.cpp:40:
In file included from
D:\projekty\msys2\clang\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114:
D:\projekty\msys2\clang\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37:
error: cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t
*') with an rvalue of type 'const wchar_t *' ... |


Regards,
Mateusz


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
ua_wcsrchr returns to wchar_t *
Date: Fri, 7 Apr 2017 10:00:26 -0700
To: Mingw-w64-public
From: David Grayson
> I did read the top two answers in the link that Norbert posted:
>
> http://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior
>
> The first answer (from ecatmur) indicates that this kind of conversion with
> a union would be undefined behavior in C++, but not C.  I'm not sure what
> else to read, except the latest C++ standard, which was quoted heavily in
> the answer.
>
> The second answer (from Bo Persson) provides a useful link to the GCC
> documentation which makes me think that GCC provides additional guarantees
> beyond what the standard says, and so this kind of conversion would
> actually be safe, in both C and C++.  Since GCC behaves that way, clang
> probably would too.  So yeah, the union conversion is probably fine because
> of the design of the compilers we care about.
>
> I think casting would work too.  When LH_Mouse's reasoned about why the
> warnings would not be a problem, Kai said:  "Each compiler has its own
> variants for this.  But well, why we should rely on such things."  Are you
> more OK with relying on the details of compiler behavior for union
> conversions than the details of compiler behavior for warnings?
>
> --David
>
> On Fri, Apr 7, 2017 at 9:31 AM, Kai Tietz  wrote:
>
>> 2017-04-07 17:21 GMT+02:00 David Grayson :
 type1 *foo(const type1 *my_const_ptr)
 {
 union {
   type1 *t1;
   const type1 *ct1;
 } v;
 v.ct1 = my_const_ptr;
 return v.t1;
 }
>>> Yes, that is sad, and it seems like just a matter of time before a C++
>>> compiler looks at the code above and reasons that the write to ct1 can be
>>> optimized away because there is no code that ever reads from ct1.  Thus
>> the
>>> read from t1 will be recognized as undefined behavior (probably called a
>>> poison value in LLVM) and anything could happen.
>> LOL  ... if a compiler modifies a technical valid language construct,
>> and produces by this optimization something it needs to warn about,
>> then the compiler has a bug.  And well, you should be sad to use such
>> a compiler, as it is broken in many aspects.
>>
>>
>>> What was the problem with Mateusz's patch?  I think people are implying
>> it
>>> results in compiler warnings, but I thought casting a pointer to a
>> pointer
>>> usually doesn't give any warnings.
>> The problem is that you seems to see an UB, where actually none is.
>> Please try read a bit about C++, compatibility to C, and what, and how
>> a union on pointer types are treated in a union (especially the part
>> about integer scalars & pointers).
>>
>> ~Kai
>>
>> PS: As you already recognized, yes the issue is to avoid warnings OP
>> doesn't expect them.
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> --
> 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



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging te

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

> Hmm, using here "wchar_t *" as cast looks wrong.  Actually we should
> use anyway PUWSTR_C instead.
I noticed it a bit too late and sent another patch casting to PUWSTR_C.
> Nevertheless we can have here a const/none-const conversion (means
> const specifiers for C-runtime function isn't regarded right?).  I
> would suggest to introduce a union-cast instead to avoid further
> warnings instead.
Conversion from const pointer to normal pointer is definitely unsafe but
that's probably what GCC just did.
I'm unsure what you mean by "union-cast" but you can commit your fix.



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

 On second though casting to "PUWSTR_C" which is  could be more appealing.
Attaching improved patch.




-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
ua_wcsrchr returns to wchar_t *
Date: Wed, 5 Apr 2017 15:06:41 +0200
To: Mingw-w64-public
From: Mateusz Mikuła
>
>  Hmm, somehow Sourcefore has lost track on this thread (you can see
> patch on the mailing list website).
>
> This time sending it as both attachment and text.
>
> From f3febf9542a6664eedc384b0d2bf63411477e141 Mon Sep 17 00:00:00 2001
> From: Mateusz Mikula 
> Date: Mon, 3 Apr 2017 13:36:36 +0200
> Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
> wchar_t *
>
> Clang doesn't allow implicit conversion form 'const wchar_t *' to
> 'wchar_t *'
>
> Signed-off-by: Mateusz Mikula 
> ---
>  mingw-w64-headers/include/stralign.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mingw-w64-headers/include/stralign.h
> b/mingw-w64-headers/include/stralign.h
> index 9b5637d6..cdb81438 100644
> --- a/mingw-w64-headers/include/stralign.h
> +++ b/mingw-w64-headers/include/stralign.h
> @@ -118,11 +118,11 @@ extern "C" {
>  
>  #ifndef __CRT__NO_INLINE
>__CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
> -if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
> +if(WSTR_ALIGNED(String)) return (wchar_t
> *)wcschr((PCWSTR)String,Character);
>  return (PUWSTR_C)uaw_wcschr(String,Character);
>}
>__CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
> -if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
> +if(WSTR_ALIGNED(String)) return (wchar_t
> *)wcsrchr((PCWSTR)String,Character);
>  return (PUWSTR_C)uaw_wcsrchr(String,Character);
>}
>  #if defined(__cplusplus) && defined(_WConst_Return)
> -- 
> 2.12.1
>
>
> -- Original Message --
> Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
> ua_wcsrchr returns to wchar_t *
> Date: Wed, 5 Apr 2017 14:26:50 +0200
> To: Mingw-w64-public
> From: Kai Tietz
>> Hello Mateusz,
>>
>> could you please re-attach, or simply inline patch to this mail?
>>
>> Thanks in advance,
>> Kai
>>
>> 2017-04-05 14:08 GMT+02:00 Mateusz Mikuła :
>>>  Ping, looks like it slipped unnoticed.
>>>
>>>
>>>
>>>
>>> -- Original Message --
>>> Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
>>> wchar_t *
>>> Date: Mon, 3 Apr 2017 14:01:00 +0200
>>> To: Mingw-w64-public
>>> From: Mateusz Mikuła
>>>> I made another attempt to build libc++ with mingw-w64 and stumbled
>>>> across Clang errors:
>>>>
>>>> |D:\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114:
>>>> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error:
>>>> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
>>>> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
>>>> return wcschr((PCWSTR)String,Character);
>>>> ^~~~
>>>> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:125:37: error:
>>>> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
>>>> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
>>>> return wcsrchr((PCWSTR)String,Character); You can see here function
>>>> that should return PUWSTR_C (aka ||'wchar_t *') returns ||'const wchar_t 
>>>> *|' instead.
>>>>
>>>> This patch solved error for Clang and caused no errors or warning for GCC.
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
&

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

 Hmm, somehow Sourcefore has lost track on this thread (you can see
patch on the mailing list website).

This time sending it as both attachment and text.

From f3febf9542a6664eedc384b0d2bf63411477e141 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula 
Date: Mon, 3 Apr 2017 13:36:36 +0200
Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
wchar_t *

Clang doesn't allow implicit conversion form 'const wchar_t *' to
'wchar_t *'

Signed-off-by: Mateusz Mikula 
---
 mingw-w64-headers/include/stralign.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/include/stralign.h
b/mingw-w64-headers/include/stralign.h
index 9b5637d6..cdb81438 100644
--- a/mingw-w64-headers/include/stralign.h
+++ b/mingw-w64-headers/include/stralign.h
@@ -118,11 +118,11 @@ extern "C" {
 
 #ifndef __CRT__NO_INLINE
   __CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
+if(WSTR_ALIGNED(String)) return (wchar_t
*)wcschr((PCWSTR)String,Character);
 return (PUWSTR_C)uaw_wcschr(String,Character);
   }
   __CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
+if(WSTR_ALIGNED(String)) return (wchar_t
*)wcsrchr((PCWSTR)String,Character);
 return (PUWSTR_C)uaw_wcsrchr(String,Character);
   }
 #if defined(__cplusplus) && defined(_WConst_Return)
-- 
2.12.1


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and
ua_wcsrchr returns to wchar_t *
Date: Wed, 5 Apr 2017 14:26:50 +0200
To: Mingw-w64-public
From: Kai Tietz
> Hello Mateusz,
>
> could you please re-attach, or simply inline patch to this mail?
>
> Thanks in advance,
> Kai
>
> 2017-04-05 14:08 GMT+02:00 Mateusz Mikuła :
>>  Ping, looks like it slipped unnoticed.
>>
>>
>>
>>
>> -- Original Message --
>> Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
>> wchar_t *
>> Date: Mon, 3 Apr 2017 14:01:00 +0200
>> To: Mingw-w64-public
>> From: Mateusz Mikuła
>>> I made another attempt to build libc++ with mingw-w64 and stumbled
>>> across Clang errors:
>>>
>>> |D:\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114:
>>> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error:
>>> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
>>> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
>>> return wcschr((PCWSTR)String,Character);
>>> ^~~~
>>> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:125:37: error:
>>> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
>>> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
>>> return wcsrchr((PCWSTR)String,Character); You can see here function
>>> that should return PUWSTR_C (aka ||'wchar_t *') returns ||'const wchar_t 
>>> *|' instead.
>>>
>>> This patch solved error for Clang and caused no errors or warning for GCC.
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

From f3febf9542a6664eedc384b0d2bf63411477e141 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula 
Date: Mon, 3 Apr 2017 13:36:36 +0200
Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

Clang doesn't allow implicit conversion form 'const wchar_t *' to 'wchar_t *'

Signed-off-by: Mateusz Mikula 
---
 mingw-w64-headers/include/stralign.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/include/stralign.h 
b/mingw-w64-headers/include/stralign.h
index 9b5637d6..cdb81438 100644
--- a/mingw-w64-headers/include/stralign.h
+++ b/mingw-w64-headers/include/stralign.h
@@ -118,11 +118,11 @@ extern "C" {

Re: [Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

 Ping, looks like it slipped unnoticed.




-- Original Message --
Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to
wchar_t *
Date: Mon, 3 Apr 2017 14:01:00 +0200
To: Mingw-w64-public
From: Mateusz Mikuła
>
> I made another attempt to build libc++ with mingw-w64 and stumbled
> across Clang errors:
>
> |D:\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114:
> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error:
> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
> return wcschr((PCWSTR)String,Character);
> ^~~~
> D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:125:37: error:
> cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
> with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String))
> return wcsrchr((PCWSTR)String,Character); You can see here function
> that should return PUWSTR_C (aka ||'wchar_t *') returns ||'const wchar_t *|' 
> instead.
>
> This patch solved error for Clang and caused no errors or warning for GCC.



signature.asc
Description: OpenPGP digital signature
--
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

[Mingw-w64-public] [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

[Mateusz Mikuła]

I made another attempt to build libc++ with mingw-w64 and stumbled
across Clang errors:

|D:\msys64\mingw64\x86_64-w64-mingw32\include\windows.h:114:
D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:121:37: error:
cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String)) return
wcschr((PCWSTR)String,Character); ^~~~
D:\msys64\mingw64\x86_64-w64-mingw32\include\stralign.h:125:37: error:
cannot initialize return object of type 'PUWSTR_C' (aka 'wchar_t *')
with an rvalue of type 'const wchar_t *' if(WSTR_ALIGNED(String)) return
wcsrchr((PCWSTR)String,Character); You can see here function that should
return PUWSTR_C (aka ||'wchar_t *') returns ||'const wchar_t *|' instead.

This patch solved error for Clang and caused no errors or warning for GCC.

From f3febf9542a6664eedc384b0d2bf63411477e141 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula 
Date: Mon, 3 Apr 2017 13:36:36 +0200
Subject: [PATCH] stralign: cast ua_wcschr and ua_wcsrchr returns to wchar_t *

Clang doesn't allow implicit conversion form 'const wchar_t *' to 'wchar_t *'

Signed-off-by: Mateusz Mikula 
---
 mingw-w64-headers/include/stralign.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mingw-w64-headers/include/stralign.h 
b/mingw-w64-headers/include/stralign.h
index 9b5637d6..cdb81438 100644
--- a/mingw-w64-headers/include/stralign.h
+++ b/mingw-w64-headers/include/stralign.h
@@ -118,11 +118,11 @@ extern "C" {
 
 #ifndef __CRT__NO_INLINE
   __CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) return wcschr((PCWSTR)String,Character);
+if(WSTR_ALIGNED(String)) return (wchar_t 
*)wcschr((PCWSTR)String,Character);
 return (PUWSTR_C)uaw_wcschr(String,Character);
   }
   __CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
-if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
+if(WSTR_ALIGNED(String)) return (wchar_t 
*)wcsrchr((PCWSTR)String,Character);
 return (PUWSTR_C)uaw_wcsrchr(String,Character);
   }
 #if defined(__cplusplus) && defined(_WConst_Return)
-- 
2.12.1


signature.asc
Description: OpenPGP digital signature
--
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

[Mateusz Mikuła]

 Sorry for the delay but I spent almost whole day in college.

Thank you for adding it, here comes small patch to test it.


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 21:19:05 -0500
To: Mingw-w64-public
From: Nightstrike
> On Mon, Mar 20, 2017 at 9:34 AM, Mateusz Mikuła  wrote:
>>  It explains why my patches created with `git format-patch` couldn't
>> make it.
>>
>> Their mime type is `text/x-diff`.
> I added text/x-diff to the list.  Give it a shot.
>
> --
> 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

From 180bffbe07c0c43e7f103debc8d8d777cb027096 Mon Sep 17 00:00:00 2001
From: Mateusz Mikula 
Date: Thu, 2 Feb 2017 12:21:45 +0100
Subject: [PATCH 3/9] fix libclang name for mingw

---
 tools/libclang/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libclang/CMakeLists.txt b/tools/libclang/CMakeLists.txt
index 477e53dd15..dc2e3538fa 100644
--- a/tools/libclang/CMakeLists.txt
+++ b/tools/libclang/CMakeLists.txt
@@ -78,7 +78,7 @@ if((NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC) AND (NOT 
MSVC))
   set(ENABLE_STATIC STATIC)
 endif()
 
-if(WIN32)
+if(MSVC)
   set(output_name "libclang")
 else()
   set(output_name "clang")
-- 
2.12.0



signature.asc
Description: OpenPGP digital signature
--
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

[Mateusz Mikuła]

 I checked it with `file --mime-type something.patch` in MSYS2 shell;
something.patch was generated by git.



-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 23:15:21 +0800
To: Mingw-w64-public
From: Liu Hao
> On 2017/3/20 22:34, Mateusz Mikuła wrote:
>>  It explains why my patches created with `git format-patch` couldn't
>> make it.
>>
>> Their mime type is `text/x-diff`.
> Isn't it our mail clients that guess MIME types of attachments? The diff 
> file doesn't have any MIME type information stored with it.
>



signature.asc
Description: OpenPGP digital signature
--
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] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

[Mateusz Mikuła]

 It explains why my patches created with `git format-patch` couldn't
make it.

Their mime type is `text/x-diff`.


-- Original Message --
Subject: Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const
LPVOID' for VerQueryValue
Date: Mon, 20 Mar 2017 00:13:44 -0500
To: Mingw-w64-public
From: Nightstrike
> Do you know what content type you attached as?  We have to explicitly
> allow each type.  The current list is:
>
> application/pgp-signature
> multipart/mixed
> multipart/alternative
> multipart/signed
> text/plain
> text/x-patch
>
> If the content type is left unspecified, then the attachment is
> deleted.  I can add anything you like.
>
> On Sun, Mar 19, 2017 at 10:30 PM, David Grayson  
> wrote:
>> NightStrike,
>>
>> The mailing list swallowed the patch in the message I sent on March 16th.
>> I can see in GMail that I did have a patch attached to my message, but no
>> attachment is visible in the archive here:
>>
>> https://sourceforge.net/p/mingw-w64/mailman/message/35729302/
>>
>> --David Grayson
>>
>> On Sun, Mar 19, 2017 at 7:03 PM, NightStrike  wrote:
>>
>>> On Mar 16, 2017 1:40 PM, "Liu Hao"  wrote:
>>>
>>> On 2017/3/17 0:51, David Grayson wrote:
 I was trying to compile Qt and I ran into an error because Qt is
 passing a const pointer to the first argument of VerQueryValue, which
 is not properly marked as const in the mingw-w64 header files.  This
 patch fixes that.
>>> Please send the patch both inline and as an attachment, since SF mailing
>>> lists swallow attachments frequently.
>>>
>>>
>>> It shouldn't. If it does, tell me and I'll address it. I believe I already
>>> fixed one issue you brought up a while ago. I haven't seen any since.
>>> 
>>> --
>>> 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



signature.asc
Description: OpenPGP digital signature
--
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] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005

[Mateusz Mikuła]

POSIX mkdir() is deprecated in favor of _mkdir() [1] and the reason of
deprecation is already explained here [2].

[1] https://msdn.microsoft.com/en-gb/library/ms235326(v=vs.140).aspx
[2] https://stackoverflow.com/a/33358701/5940067


On 11.03.2017 01:01, sisyph...@optusnet.com.au wrote:
> -Original Message- 
> From: Grégory Vanuxem
> Sent: Saturday, March 11, 2017 2:02 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005
>
>
>> But here comes my problem :
>> In FriCAS there is a function to create a directory :
>>
>> --
>> /* Make a directory returning 0 for success and -1 for failure */
>>
>> int
>> makedir(char *path)
>> {
>> #ifdef S_IRWXO
>>return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );
>> #else
>>return ( mkdir (path) );
>> #endif
>> }
>> -
> Is it the case that,in your earlier builds, S_IRWXO was *not* defined ?
> And this is the first time you've built with S_IRWXO defined ?
>
> My belief is that mkdir() must only ever be called on Windows with *one*
> argument.
> Therefore the correct thing for FricAS to do would be to replace:
>
> #ifdef S_IRWXO
> with:
> #if defined(S_IRWXO) && !defined(_WIN32)
>
> At least, that's the approach I've always taken.
>
> I have no knowledge of what "MINGW_ATTRIB_DEPRECATED_MSVC2005" is about.
>
> Cheers,
> Rob
>
>
> --
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




signature.asc
Description: OpenPGP digital signature
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Align thread entry point stack

[Mateusz Mikuła]

Forwarding Aleksey's message from MSYS2 discussion:

@mati865  Sorry for long reply. I email
directly to Kai 22 aug 2016:
"Yes i test patch. Patch fix crash: ffmpeg -f lavfi -i testsrc -vcodec
libvpx -threads 2 -f null -
problem discuss: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2236
Similar patch already integrated in libvpx. libvpx has integrated thread
support together with phtreads.
https://chromium-review.googlesource.com/#/c/364140/";


W dniu 22.01.2017 o 11:36, Adrien Nader pisze:
> Hi,
>
> I've recently re-stumbled upon this. As far as I can tell it hasn't been
> commited. Was there some more discussion on the topic or did it simply
> get forgotten?
>



signature.asc
Description: OpenPGP digital signature
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: mungw-w64-v5.0.1

[Mateusz Mikuła]

 > ./configure --build alias - -host -alias --target -alias

It is wrong, because there is no arch named 'alias'.
Look at
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-crt-git/PKGBUILD#L57
,
"${MINGW_CHOST}" is expanded as 'x86_64-w64-mingw32'.

2017-02-25 8:50 GMT+01:00 Adrien Nader :

> On Sat, Feb 25, 2017, JonY wrote:
> > On 02/25/2017 12:54 AM, Robert May wrote:
> > > --build alias - -host -alias --target -alias
> >
> > How did you even get that?
>
> --{build,host,target}-alias are valid configure options as far as I
> remmeber. However noone ever uses them. And here the copy-paste went
> completely wrong and inserted extra spaces at random places. That said,
> I don't know of any place that tells to use these options and no other
> one.
>
> --
> Adrien Nader
>
> 
> --
> 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: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz Mikuła]

Hello Jacek,

> Thanks for testing. Sadly, I found that the patch wasn't correct. Could
you please try the attached one?

New patch is also fine.

> Thanks, but I'd be more interested in documentation how to get cross
compilation setup with clang + mingw-w64. I did one in the past, but it
required patching clang and llvm and working around misc problems I
don't quite remember in details.

I haven't tried but I doubt it will be smooth.

2017-02-17 12:55 GMT+01:00 Jacek Caban :

> Hi Mateusz,
>
> On 17.02.2017 00:06, Mateusz Mikuła wrote:
> > Hello Jacek,
> >
> > With this patch clang builds example code from first message with and
> > without `-fms-extensions`.
>
> Thanks for testing. Sadly, I found that the patch wasn't correct. Could
> you please try the attached one?
>
> > I can provide prebuild clang-svn pacakge for msys2.
>
> Thanks, but I'd be more interested in documentation how to get cross
> compilation setup with clang + mingw-w64. I did one in the past, but it
> required patching clang and llvm and working around misc problems I
> don't quite remember in details.
>
> 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
>
>
--
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: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz Mikuła]

Hello Jacek,

With this patch clang builds example code from first message with and
without `-fms-extensions`.
I can provide prebuild clang-svn pacakge for msys2.

Thanks,
Mateusz


2017-02-16 15:06 GMT+01:00 Jacek Caban :

> Hi Mateusz,
>
> Could you please try the attached patch? It should existing failures on
> clang. It also changes our generic guard to take __has_builtin into
> account, so this should prevent problems in the future, if clang
> introduces more builtins, but I don't have clang setup to test it.
>
> Thanks,
> Jacek
>
> On 09.02.2017 01:35, Mateusz Mikuła wrote:
> > You are right David and now I remember the thing about ms-extensions.
> > Declspec was part of those extensions and enabling it by default caused
> > errors with specific code so declspec was changed to general attribute
> > instead.
> > Since I have clang git build (trying to upstream some patches used by
> > MSYS2), I tried it also:
> > https://paste.ubuntu.com/23957478/
> >
> > While for 3.9.x Clang `-fms-extensions` didn't hurt, master branch
> require
> > some corrections but it is another issue.
> >
> >
> > 2017-02-09 0:15 GMT+01:00 David Grayson :
> >
> >> I can confirm that MSYS2's x86_64 clang++ compiler does not support
> >> __popcnt but does support __builtin_popcount.  I looked into it a
> >> little bit, and found out that the clang commit that adds the __popcnt
> >> builtins is very recent (September 2016).  I seems like it has not
> >> made it into a release yet.
> >>
> >> Here is the commit:
> >>
> >> https://github.com/llvm-mirror/clang/commit/
> 5eb95c4c284486351e3ed0fdad011a
> >> cf41540c8b
> >>
> >> The source code archive that Alexey used to build the MSYS2 clang++
> >> does not have the changes from that commit in it:
> >>
> >> http://repo.msys2.org/mingw/sources/mingw-w64-clang-3.9.1-3.src.tar.gz
> >>
> >> I don't intend to submit any more patches for this issue.  Jacek has
> >> already committed my patch to mingw-w64 (thanks!).  Once the new
> >> version of clang comes out and people start using it there should not
> >> be any problems.  If any clang users are itching to use __popcnt
> >> before the new version of clang comes out, they can easily remove the
> >> #if I put in intrin-impl.h.  They could also use __has_builtin in
> >> intrin-impl.h to detect whether clang has the builtin or not.
> >>
> >> Mateusz, the "CodeGen" folder in clang is not just used for MSVC libs,
> >> it has tons of general-purpose code for generating LLVM code from
> >> C/C++ code.
> >>
> >> --David Grayson
> >>
> >> On Wed, Feb 8, 2017 at 1:24 PM, Mateusz  wrote:
> >>> Opps, gmail put output into quote. Improved version:
> >>> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> >>> popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16'
> >>> unsigned short usr = __popcnt16(us[i]);
> >>>  ^
> >>> popcnt.cc:17:24: error: use of undeclared identifier '__popcnt'
> >>> unsigned int uir = __popcnt(ui[i]);
> >>>^
> >>> popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did
> >> you
> >>> mean '_popcnt64'?
> >>> unsigned __int64 ulr = __popcnt64(ul[i]);
> >>>^~
> >>>_popcnt64
> >>> D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1:
> >> note:
> >>> '_popcnt64' declared here
> >>> _popcnt64(long long __A)
> >>> ^
> >>> 3 errors generated.
> >>>
> >>>
> >>>
> >>> 2017-02-08 22:22 GMT+01:00 Mateusz :
> >>>
> >>>> I think ms-extensions was made default option for mingw and msvc clang
> >> and
> >>>> codegen is used only for creating msvc libs. Here is Clang output
> >> anyway:
> >>>> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> >>>> popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16'
> >>>> unsigned short usr = __popcnt16(us[i]);
> >>>>  ^
> >>>> popcnt.cc:17:24: error: use of undeclared identifier '__popcnt'
> >>>> unsigned int uir = __popcnt(ui[i]);
> >>>>^
> >>

Re: [Mingw-w64-public] [PATCH] intrin-impl.h: Added __popcnt16, __popcnt, and __popcnt64.

[Mateusz Mikuła]

You are right David and now I remember the thing about ms-extensions.
Declspec was part of those extensions and enabling it by default caused
errors with specific code so declspec was changed to general attribute
instead.
Since I have clang git build (trying to upstream some patches used by
MSYS2), I tried it also:
https://paste.ubuntu.com/23957478/

While for 3.9.x Clang `-fms-extensions` didn't hurt, master branch require
some corrections but it is another issue.


2017-02-09 0:15 GMT+01:00 David Grayson :

> I can confirm that MSYS2's x86_64 clang++ compiler does not support
> __popcnt but does support __builtin_popcount.  I looked into it a
> little bit, and found out that the clang commit that adds the __popcnt
> builtins is very recent (September 2016).  I seems like it has not
> made it into a release yet.
>
> Here is the commit:
>
> https://github.com/llvm-mirror/clang/commit/5eb95c4c284486351e3ed0fdad011a
> cf41540c8b
>
> The source code archive that Alexey used to build the MSYS2 clang++
> does not have the changes from that commit in it:
>
> http://repo.msys2.org/mingw/sources/mingw-w64-clang-3.9.1-3.src.tar.gz
>
> I don't intend to submit any more patches for this issue.  Jacek has
> already committed my patch to mingw-w64 (thanks!).  Once the new
> version of clang comes out and people start using it there should not
> be any problems.  If any clang users are itching to use __popcnt
> before the new version of clang comes out, they can easily remove the
> #if I put in intrin-impl.h.  They could also use __has_builtin in
> intrin-impl.h to detect whether clang has the builtin or not.
>
> Mateusz, the "CodeGen" folder in clang is not just used for MSVC libs,
> it has tons of general-purpose code for generating LLVM code from
> C/C++ code.
>
> --David Grayson
>
> On Wed, Feb 8, 2017 at 1:24 PM, Mateusz  wrote:
> > Opps, gmail put output into quote. Improved version:
> > $ clang++ popcnt.cc -std=c++14 -fms-extensions
> > popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16'
> > unsigned short usr = __popcnt16(us[i]);
> >  ^
> > popcnt.cc:17:24: error: use of undeclared identifier '__popcnt'
> > unsigned int uir = __popcnt(ui[i]);
> >^
> > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did
> you
> > mean '_popcnt64'?
> > unsigned __int64 ulr = __popcnt64(ul[i]);
> >^~
> >_popcnt64
> > D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1:
> note:
> > '_popcnt64' declared here
> > _popcnt64(long long __A)
> > ^
> > 3 errors generated.
> >
> >
> >
> > 2017-02-08 22:22 GMT+01:00 Mateusz :
> >
> >> I think ms-extensions was made default option for mingw and msvc clang
> and
> >> codegen is used only for creating msvc libs. Here is Clang output
> anyway:
> >>
> >> $ clang++ popcnt.cc -std=c++14 -fms-extensions
> >> popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16'
> >> unsigned short usr = __popcnt16(us[i]);
> >>  ^
> >> popcnt.cc:17:24: error: use of undeclared identifier '__popcnt'
> >> unsigned int uir = __popcnt(ui[i]);
> >>^
> >> popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64'; did
> you
> >> mean '_popcnt64'?
> >> unsigned __int64 ulr = __popcnt64(ul[i]);
> >>^~
> >>_popcnt64
> >> D:\msys64\mingw64\bin\..\lib\clang\3.9.1\include\popcntintrin.h:90:1:
> >> note: '_popcnt64' declared here
> >> _popcnt64(long long __A)
> >> ^
> >> 3 errors generated.
> >>
> >> 2017-02-08 20:10 GMT+01:00 David Grayson :
> >>
> >>> Mateusz, thanks for looking in to this.
> >>>
> >>> Here are the relevant lines from the clang source code that indicate
> >>> that it supports those builtins:
> >>>
> >>> https://github.com/llvm-mirror/clang/blob/3e45634a7f951c2306
> >>> e4b368f9fb8c8d80c48273/include/clang/Basic/Builtins.def#L760-L762
> >>> https://github.com/llvm-mirror/clang/blob/4cedfcc1ecf8387082
> >>> 183508604b7f47c634f708/lib/CodeGen/CGBuiltin.cpp#L804-L821
> >>>
> >>> Can you try your clang test again with the "-fms-extensions" argument?
> >>>
> >>> (I tried to test clang myself earlier but I had various issues.  I
> >>> could probably try again tonight if you don't want to.)
> >>>
> >>> --David
> >>>
> >>> On Wed, Feb 8, 2017 at 10:54 AM, Mateusz  wrote:
> >>> > MSYS2 native Clang test-popcnt.cpp:
> >>> >
> >>> > $ clang++ popcnt.cc -std=c++14
> >>> > popcnt.cc:9:26: error: use of undeclared identifier '__popcnt16'
> >>> > unsigned short usr = __popcnt16(us[i]);
> >>> >  ^
> >>> > popcnt.cc:17:24: error: use of undeclared identifier '__popcnt'
> >>> > unsigned int uir = __popcnt(ui[i]);
> >>> >^
> >>> > popcnt.cc:26:28: error: use of undeclared identifier '__popcnt64';
> did
> >>> you
> >>> > mean '_popcnt64'?
> >>> > unsigned __int64