Re: [Mingw-w64-public] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

On 2017/2/8 1:45, Ricardo Constantino wrote: > Should be fixed with > https://github.com/Alexpux/MINGW-packages/commit/ba282a67e, but I thought > someone would've reported it to upstream by now? Probably you could comment this PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506. -- Best

Re: [Mingw-w64-public] bug in mingw-w64 tanh()

On 2017/3/24 23:58, Liu Hao wrote: > On 2017/3/24 23:08, Jeroen Ooms wrote: >> I was able to reproduce the problem on msys2 with gcc 6.3: >> >> #include >> #include >> #include >> >> int main(){ >> std::cout << std::fixed;

Re: [Mingw-w64-public] bug in mingw-w64 tanh()

both can be NaNs we can replace it with `tanh(2 * __real__ z)` directly ({sin,cos,tan}h functions are part of MSVCRT). The attached patch should fix the problem. I am not a mathematician, though. So please correct me. -- Best regards, LH_Mouse From a46cc6ea45467cad2b0669417fdbe7afed78dade Mon Sep

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

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

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

On 2017/3/20 20:49, Jon Turney wrote: > Windows 10 now has a separate exception for OutputDebugStringW, rather than > converting the string to ANSI and raising DBG_PRINTEXCEPTION_C. > > (See > https://ntquery.wordpress.com/2015/09/07/windows-10-new-anti-debug-outputdebugstringw/) It can also be

Re: [Mingw-w64-public] [PATCH] Update definitions in 64bit ntdll.def to match the 32bit one.

On 2017/3/21 15:20, Tamar Christina wrote: > As discussed on IRC this patch will normalise the behavior between the 32bit > and the 64bit > ntdll.def file so that both have the same definitions as DATA. The attachment seems swallowed again. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] pdh.h: use PDH_FUNCTION for Vista+ functions

On 2017/3/16 13:20, Ozkan Sezer wrote: > On 3/16/17, Liu Hao <lh_mo...@126.com> wrote: >> On 2017/3/16 5:26, Jon Turney wrote: >>> Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are >>> correctly decorated with WINAPI (= stdcall on x86), so l

Re: [Mingw-w64-public] [PATCH] pdh.h: use PDH_FUNCTION for Vista+ functions

On 2017/3/16 5:26, Jon Turney wrote: > Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are > correctly decorated with WINAPI (= stdcall on x86), so linkage works > correctly on x86. This is indeed how Microsoft people declare these functions. Is this patch ok to apply? However,

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

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.

Re: [Mingw-w64-public] [PATCH] (again) Use LPCVOID instead of 'const LPVOID' for VerQueryValue.

On 2017/3/17 17:43, Kai Tietz wrote: > Ok for master. Thanks for the review. Pushed to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites,

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

On 2017/3/22 20:46, JonY wrote: > On 03/22/2017 10:39 AM, Liu Hao wrote: >> On 2017/3/22 3:59, Jon Turney wrote: >>> On 21/03/2017 07:43, Ruben Van Boxem wrote: >>> This value is not guarded in that way in the SDK. I'm not sure why that >>> might be. &g

Re: [Mingw-w64-public] [PATCH] (again) Use LPCVOID instead of 'const LPVOID' for VerQueryValue.

On 2017/3/17 11:09, David Grayson wrote: > Here is that patch again. Thanks! These new prototypes match https://msdn.microsoft.com/en-us/library/windows/desktop/ms647464.aspx , so I think it is ok to apply, no? -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

On 2017/4/4 2:11, Jacek Caban wrote: > I'm sorry to jump into discussion so late. The patch looks good to me. OK I pushed it to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the

Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library

On 2017/4/9 22:59, Edward Diener wrote: > Are you saying that I have to build gcc-6.3 myself on Windows, rather > than juat install it from mingw-w64-install, in order to use your library ? Yes. However I also build it constantly, which is available here: . These

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

On 2017/4/4 1:19, David Grayson wrote: > What you say matches what I got from my experiments, but it's odd that it > doesn't match the GCC documentation I linked to, which says: > > If you specify both inline and extern in the function definition, then > the definition is used only for inlining.

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

On 2017/4/4 0:48, David Grayson wrote: > I'm a bit confused about the different inlining keywords. From the GCC > documentation for inlining in the C language ( > https://gcc.gnu.org/onlinedocs/gcc/Inline.html ) it seemed like "extern > inline" (i.e. __CRT_INLINE) would be the best thing to use,

Re: [Mingw-w64-public] [PATCH] strsafe.h: Change __inline to __CRT_INLINE

r this issue. Please test. -- Best regards, LH_Mouse From f2f652c023ad1320f69bd7d5f0d5c47376056869 Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.com> Date: Mon, 3 Apr 2017 02:00:15 +0800 Subject: [PATCH] include/strsafe.h: Fix warning 'inline function declared but never defin

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

On 2017/4/6 20:47, Kai Tietz wrote: > True. The reason why we prefer such patter is that it works in both > languages as desired. Otherwise we would be in need to write > different variants for the languages C/C++. This looks backward, and > it still doesn't make sure that there might be

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

On 2017/4/5 21:51, Mateusz Mikuła wrote: > 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. Take a look at the prototype of the `strchr` function in the C standard

Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library

On 2017/4/10 10:04, Edward Diener wrote: > Thanks for the link. I am curious though why you could not have supplied > alternative versions of the mingw-64/gcc threading library rather than > entirely new builds of mingw-64/gcc ? Did you actually have to modify > other modules of mingw-64/gcc to

Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library

On 2017/4/9 8:12, Edward Diener wrote: > 1) if mcfgthread replaces the mingw-64/gcc-6.3 threading library when used. It takes the place of winpthreads completely. > 2) if it replaces the mingw-64/gcc-6.3 threading library even when I had > installed mingw-64/gcc-6.3 with posix threading support

[Mingw-w64-public] [PATCH 2/2] winpthreads/src/thread.c: Fix SetThreadName().

From c2f24277dbc6878b98a5f5174a01b103d16d5bcd Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.com> Date: Fri, 10 Mar 2017 15:49:35 +0800 Subject: [PATCH 2/2] winpthreads/src/thread.c: Fix SetThreadName(). MSDN says the struct should be passed in as an array of ULONG_PTRs. Don't use

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

On 2017/3/8 11:27, Liu Hao wrote: On 2017/3/8 4:31, Mateusz Mikuła wrote: Forwarding Aleksey's message from MSYS2 discussion: [...] 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

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

On 2017/3/13 20:17, Riot wrote: > I have tried replacing -flto with -whopr as suggested at > https://sourceforge.net/p/mingw-w64/wiki2/LTO%20and%20GCC/, but this is now > an unrecognised commandline option. Try `-fwhole-program`. -- Best regards, LH_Mouse

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

On 2017/3/10 15:41, Liu Hao wrote: > On 2017/3/8 11:27, Liu Hao wrote: >> On 2017/3/8 4:31, Mateusz Mikuła wrote: >>> Forwarding Aleksey's message from MSYS2 discussion: >>> [...] >>> W dniu 22.01.2017 o 11:36, Adrien Nader pisze: >>>> Hi, >>&g

Re: [Mingw-w64-public] Fwd: Fix for winreg.h

On 2017/3/14 18:57, JonY wrote: > Looks like LH has already applied this to master. Yes I pushed it a couple of days ago. He said his mails were suspended on this ML (and it seemed so). Best regards, LH_Mouse -- Check

Re: [Mingw-w64-public] mkdir and MINGW_ATTRIB_DEPRECATED_MSVC2005

On 2017/3/11 10:22, sisyph...@optusnet.com.au wrote: > So ... how do I see the associated "deprecation" warning when compiling a > program that contains a call to "mkdir" ? The warning is enabled by adding `#define __MINGW_MSVC_COMPAT_WARNINGS 1` before #include'ing any headers or use the

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

On 2017/3/8 4:31, Mateusz Mikuła wrote: > Forwarding Aleksey's message from MSYS2 discussion: > [...] > 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

[Mingw-w64-public] [PATCH] winreg.h: Fix declaration of RegSetKeyValueW

janisozaur on IRC reported a bug about `RegSetKeyValueW()` today. According to MSDN the parameters `lpSubKey` and `lpValueName` of `RegSetKeyValue()` should have type `LPCTSTR`, hence in the case of `RegSetKeyValueW()` they should have type `LPCWSTR`. In our headers they used to have type

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

On 2017/4/8 1:00, David Grayson wrote: > 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

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

On 2017/4/7 8:11, Norbert Pfeiler wrote: > Wasn’t LH_Mouse’s point that even if the warning is explicitly turned on it > wouldn’t be shown to the user? > > The situation for unions is different in C and C++: (I don’t think that > it’s just about constness changes anything) >

Re: [Mingw-w64-public] Problem using gcc in MSYS2 shell

On 2017/4/7 0:56, Edward Diener wrote: > When trying to compile a project in MSYS2 using mingw-64/gcc I get this > error: > (... abridgement ...) This was an oversight. I replied with detailed information on msys2-users. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] usbspec.h: Add some missing structs and definitions.

On 2017/4/18 0:47, David Grayson wrote: > Hello. The attached patch adds some definitions and structs that were > missing from usbspec.h. I needed this to build the latest version of > Microsoft's usbview program ( > https://github.com/DavidEGrayson/nixcrpkgs/tree/master/pkgs/usbview ). I

Re: [Mingw-w64-public] [PATCH] usbspec.h: Add some missing structs and definitions.

On 2017/4/18 0:47, David Grayson wrote: > Hello. The attached patch adds some definitions and structs that were > missing from usbspec.h. I needed this to build the latest version of > Microsoft's usbview program ( > https://github.com/DavidEGrayson/nixcrpkgs/tree/master/pkgs/usbview ). It looks

Re: [Mingw-w64-public] [Project News|New Builds]

On 2017/8/15 15:16, Adrien Nader wrote: On Tue, Aug 15, 2017, niXman wrote: Liu Hao 2017-08-15 05:59: When I click the Register button the page reloads and nothing happens thereafter. +1 Have you checked your emails, including the spam folder? Yes. There are no such mails. -- Best

Re: [Mingw-w64-public] [Project News|New Builds]

On 2017/8/15 3:22, Adrien Nader wrote: On Mon, Aug 14, 2017, niXman wrote: Norbert Pfeiler 2017-08-14 18:19: What do you want the contents to be? (regarding it currently shows 2 versions) I usually update Msys2 and Arch where only 1 version applies. will be better if you explain how I can

Re: [Mingw-w64-public] [PATCH] VirtualProtect problem in pseudo-reloc.c

On 2017/7/9 14:06, Arthur D. Edelstein wrote: Hi, I am proposing a patch here to deal with a problem found in a cross-compiled Tor Browser and Tor Expert Bundle. Using VMMap on Windows, we observed Execute/Read/Write (XRW) and Execute/Copy-on-Write pages (X/COW) in some DLLs and the Tor

Re: [Mingw-w64-public] [PATCH] VirtualProtect problem in pseudo-reloc.c

On 2017/7/10 22:34, Kai Tietz via Mingw-w64-public wrote: Hi, yes, the patch looks fine to me. Your changes looking fine to me. Nevertheless we should just put this code change just in master, as we need to let people test new code. Please go ahead and commit to master. Thanks, Kai Done.

Re: [Mingw-w64-public] [PATCH] amended function prototype of function 'glob' in glob.h

On 2017/7/3 19:04, Jannick wrote: Attached a tiny patch to glob.h which remedies a function prototype definition error thrown upon compilation. On one of cygwin's user lists I was deferred to this one here. I bumped into that issue when compiling with cygwin's i686-pc-mingw32. I am hoping

Re: [Mingw-w64-public] [PATCH] Add ShutdownBlockReason* to lib64/user32.def

On 2017/4/22 6:32, Aman Gupta wrote: > From: Aman Gupta > > These are already included as part of lib32/user32.def > > Fixes https://sourceforge.net/p/mingw-w64/bugs/526/ This looks reasonable to me. I may commit it a few hours later. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] Update 64bit user32.def

On 2017/4/22 10:35, JonY wrote: > Patch OK for master? Oh well this supersedes the previous patch. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites,

Re: [Mingw-w64-public] GUID definition in guiddef.h

On 2017/4/28 21:38, Vincent Torri wrote: > ok, the MSDC doc i mentioned is incorrect... > > thank you My pleasure. Nevertheless it isn't being incorrect at all. It is just the doc about the human readable format and is irrelevant to the binary representation. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] GUID definition in guiddef.h

On 2017/4/28 19:38, Vincent Torri wrote: > Hello > > in guiddef.h, a GUID is a struct organized as : 4 bytes, 2 bytes 2 > bytes and 8 times 1 byte > > but according to > https://msdn.microsoft.com/en-us/library/dd354925.aspx at the bottom : > > "The correct format of the GUID string is >

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

On 2017/8/2 19:42, Madalinski Piotr wrote: Hi all, I'm having trouble with getting correct section sizes under MinGW. The example below demonstrates the issue: (... abridgement ...) Adding align(1) attribute to the data definition is a workaround, that fixes the problem, but due to external

Re: [Mingw-w64-public] [Project News|New Builds]

has been devised but not deployed yet. This should happen soon but in the meantime I have created and configured an account for you and Liu Hao by hand. I will send the credentials by mail in a minute. Gotcha. Thanks for your work! :> -- Best regards, LH_Mo

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

On 2017/5/2 3:08, David Grayson wrote: > Oops, I should have learned my lesson. Well, here it is again. I think my > original email 6 days ago was good though. I did see the patch and we had a discussion on irc. That attribute seemed to have been removed for a reason, which otherwise caused

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 23:12, David Grayson wrote: > When you say "optimal", what are you optimizing for? > For decreasing object file sizes and link time, apparently. > The UsbView code uses that header file in several different translation > units, so you end up having a bunch of duplicate GUID

Re: [Mingw-w64-public] winpthreads and gcc 7.1

On 2017/5/3 18:56, Christer Solskogen wrote: > On 03.05.2017 10.23, Liu Hao wrote: >> On 2017/5/3 15:35, Christer Solskogen wrote: >>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch) >>> with gcc 7.1. >> Please try the attache

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/11 23:11, Kai Tietz wrote: > I would prefer this too, but I don't believe that we can convince > libstdc++ maintainers to modify their code for this. Sadly the MS' > platform sdk defines a lot of stuff, which collides some times with > some projects. We made about this already a lot of

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/11 21:51, David Grayson wrote: > Unfortunately, my patch seems to break several classes in libstdc++, > preventing Qt from building. The problem is that driverspecs.h defines > __in to be empty so we can compile Microsoft-type code that uses __in as a > source annotation on function

[Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

Forwarded Message Subject: Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h. Date: Wed, 10 May 2017 08:24:25 -0700 From: David Grayson <davidegray...@gmail.com> To: Liu Hao <lh_mo...@126.com> OK, thanks. I've attached a new

Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/10 23:24, David Grayson wrote: > OK, thanks. I've attached a new patch where the #include is after the > __cplusplus stuff. > > I also included a second patch that will add an include guard for > specstrings.h, since Microsoft seems to do that too. > > driverspecs.h is also missing

Re: [Mingw-w64-public] [PATCH] comment out '__in' and '__out' from driverspecs.h for compatibility with libstdc++

On 2017/5/17 23:04, David Grayson wrote: > Now that I think about it again, given that driverspecs.h does not > define __in or __out, I am actually in favor of Mateusz's patch now, > because it will make mingw-w64 closer to the official Windows headers. ... no, because you no longer have `__in` or

Re: [Mingw-w64-public] __builtin_isnanl() and invalid x87 80-bit floating point numbers

On 2017/5/16 0:43, Vincent Lefevre wrote: > On 2017-05-15 22:35:33 +0800, Liu Hao wrote: >> Yeah but `printf()` from glibc doesn't think it is a NaN... From >> your point of view, is this a glibc bug? > > I think so. If I understand correctly, the output of floating-

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/16 18:09, Jonathan Wakely wrote: > Hmm, if it's not defined when compiling with GCC then where does the > conflict come from? > These macros weren't there until recently because of the feature request by David Grayson. They don't exist in any release versions of MinGW-w64 so there is

Re: [Mingw-w64-public] Fwd: Re: [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/16 17:35, Jonathan Wakely wrote: > On 11 May 2017 at 17:55, David Grayson wrote: >> Hello, gcc-help. >> >> There is an incompatibility between libstdc++ and the headers provided >> by Microsoft and mingw-w64, because libstdc++ uses __in as a parameter >> name in several places while the

Re: [Mingw-w64-public] [PATCH] Include driverspecs.h in specstrings.h.

On 2017/5/10 10:34, David Grayson wrote: > This patch adds "#include " near the end of specstrings.h, > because the same is done in Microsoft's version of specstrings.h. With > this patch, I am able to build Microsoft's devcon utility without > modification. Thanks! You must `#include` that

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

On 2017/6/12 23:17, Martell Malone wrote: In that case, I think the best course of immediate action is to bump to Windows 7 as Kai suggested. If someone has the time to implement a configure option for changing this default like Ruben suggest that would be a great. Here is a patch for the

Re: [Mingw-w64-public] [PATCH] strsafe.h: Added missing _STRSAFE_EXTERN_C in cases when inlining is disables.

On 2017/6/20 1:40, Jacek Caban wrote: Please review. Signed-off-by: Jacek Caban --- mingw-w64-headers/include/strsafe.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) We might have to test this patch with different `-std=` options with different

Re: [Mingw-w64-public] Does clang sanitizers supposed to work on mingw64?

On 2017/6/20 2:16, Lev Serebryakov wrote: Hello Mingw-w64-public, I have installed: mingw-w64-x86_64-clang 4.0.0-1 mingw-w64-x86_64-clang-analyzer 4.0.0-1 mingw-w64-x86_64-clang-tools-extra 4.0.0-1 mingw-w64-x86_64-compiler-rt 4.0.0-1 And I could not link project which is compiled with

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

On 2017/6/22 6:30, Lev Serebryakov wrote: Hello Lev, Wednesday, June 21, 2017, 11:41:45 PM, you wrote: So, I need to printf() uint64_t in my project, which is built in strict ISO C11 mode and with all warnings enabled. If I try to use "%llu" I get warning that "unknown conversion type

Re: [Mingw-w64-public] how to printf() 64-bit integer in 64-bit compiler in strict ISO mode with all warnings enabled?

Patch attached. -- Best regards, ltpmouse From 35656690a3eb69ac5694de27081e9213df2eec79 Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.com> Date: Tue, 27 Jun 2017 23:57:39 +0800 Subject: [PATCH] mingw-w64-headers/crt/_mingw_print_pop.h: Do not check for _INC_STDIO or _WSTDIO_D

[Mingw-w64-public] [PATCH] Fix compiler errors on MinGW-w64 due to identifier collision with macros.

The attached patch was generated by running the following command in GCC source tree cloned from git://gcc.gnu.org/git/gcc.git : --- $ git checkout gcc-7-branch $ nano libstdc++-v3/doc/xml/manual/appendix_contributing.xml # Append the

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

On 2017/5/22 2:05, Martell Malone wrote: > Context: libc++ uses strftime_l now > > Please Review The DEF files are generated from DLLs. I don't have Win10 at hand so I have asked jon_y on IRC to update them. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [Patch] normalize strftime and strftime_l

On 2017/5/22 18:43, JonY wrote: > On 05/22/2017 07:57 AM, Liu Hao wrote: >> On 2017/5/22 2:05, Martell Malone wrote: >>> Context: libc++ uses strftime_l now >>> >>> Please Review >> The DEF files are generated from DLLs. I don't have Win10 at hand so I

Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by unprivileged users

On 2017/5/27 21:35, JonY wrote: On 05/27/2017 11:14 AM, Samuel Leslie wrote: The MSDN documentation doesn't appear to have been updated yet: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363866(v=vs.85).aspx But you can find the details on the official developer blog:

Re: [Mingw-w64-public] [PATCH] Add flag for symlink creation by unprivileged users

On 2017/5/28 11:50, Samuel Leslie wrote: Oh dear. Take two! *crosses fingers* Thanks for the patch, I pushed it to master. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most

Re: [Mingw-w64-public] C++ cout executable size

On 2017/6/2 20:21, bob by wrote: 2017-06-02 16:05 GMT+04:00 JonY : On 06/02/2017 11:47 AM, bob by wrote: Wonder why including bloats my exe file so much (extra 900 KiB, with statically linked libraries), even if nothing from there is used. Why cout requires

Re: [Mingw-w64-public] C++ cout executable size

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

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

* 1 / 8 = 1` hence the result is correct. But it still does not agree with `printf` from MSVCRT. -- Best regards, LH_Mouse From ff27b6d4d605b8296f814855f183e790b65183d3 Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.com> Date: Thu, 15 Jun 2017 11:43:15 +0800 Subject: [PATCH] mingw-w64-cr

Re: [Mingw-w64-public] mingw-w64-tools - configure.ac and Makefile.am for autoconf

On 2017/6/15 14:00, J. Peter Mugaas wrote: I hope this works. Please send attachments in plain text formats. If your client has trouble doing that, you can usually force it by adding a `.txt` extension. Don't forget to carry a copy of the patch inline. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] winpthreads and gcc 7.1

On 2017/5/4 13:54, Daniel Santos wrote: > I see one in libgcc, but I guess you would have to add that to your > link. I presume it's in the dynamic portion. As Kai said yesterday on IRC, in the case of cross compiling libpthread has to be available prior to libgcc. That is the reason why we link

[Mingw-w64-public] Implement weak __divmoddi4() and __udivmoddi4() for internal use by the CRT and winpthreads?

Hello all, Since GCC 7, a new function `__divmoddi4()` is added in libgcc. When GCC performs division of two 64-bit integers on i686, a call to this function is emitted, which could result in undefined references to this function when we are building part of the CRT (winpthreads for example,

[Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.

. (I really hate this C-ish code but this way it looks like how `__udivdi3` was implemented.) -- Best regards, LH_Mouse From 04f0579cb7e2f294e1e3ad2be18b8d059546208f Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.com> Date: Wed, 3 May 2017 15:52:32 +0800 Subject: [PATCH] winpthrea

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

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

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

On 2017/5/2 12:04, David Grayson wrote: > Thanks for the info. > > I used "git blame" on guiddef.h and it looks like the logic has been the > same since 2007. I don't see any sign that Kai removed the > DECLSPEC_SELECTANY from the GUID declarations, as far as I know it was just > always missing.

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

Kai, did you mean this patch was ok for master? -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/2 18:38, Kai Tietz wrote: > I think, it is worth a try. In general it looks sensible. As you wish. -- Best regards, LH_Mouse -- Check out the vibrant tech community on one of the world's most engaging tech

Re: [Mingw-w64-public] winpthreads and gcc 7.1

On 2017/5/3 15:35, Christer Solskogen wrote: I'm having a hard time (cross) compiling winpthreads (from 5.x branch) with gcc 7.1. Please try the attached patch. -- Best regards, LH_Mouse From 4fa48b2af092a3b8615cef39b6e0036e20481c3f Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 6:23, Mateusz wrote: > W dniu 2017-05-02 o 13:08, Liu Hao pisze: >> On 2017/5/2 18:38, Kai Tietz wrote: >>> I think, it is worth a try. In general it looks sensible. >> As you wish. > > For GCC 7.1 and 6.3 the patch is OK. > > For GCC 5.4 is

Re: [Mingw-w64-public] [PATCH] guiddef.h: Use __declspec(selectany) on GUID declarations.

On 2017/5/3 9:33, Liu Hao wrote: > Kai, should we revert it? We have to deal with the multiple definition > error thereafter. > A number of UUIDs/GUIDs are suffering from such multiple definitions, which can be discovered using the following commands: ```bash grep -EhrI '^DEFINE_(GUI

[Mingw-w64-public] Successful bootstrap of GCC 7.1.1 targeting {i686, x86_64}-w64-mingw32 with MCF thread model

Hello all, This message indicates success of bootstrapping GCC 7.1.1 on i686-w64-mingw32 and x86_64-w64-mingw32 with MCF thread model. You may get prebuilt binaries at . Special thanks to MSYS2 for the gcc-git package, which this work is largely based on. Both of

Re: [Mingw-w64-public] About Multiversion

On 2017/5/5 23:44, Tony Zhao wrote: > Hello there!I'm a senior high school student in China. I am a member > preparing for the Olympiad in Informatics using your Mingw-w64. It's nice > however around us there are two main G++s:4.8.4 which is used in our Online > Judge system and in the

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

On 2017/10/12 15:10, Frédéric wrote: Hi, I am using mingw w64 5.0.2 on a linux machine with gcc/g++ 7.2.0. I noticed that the macro WIN32 is: - defined if -std=gnu++{98,11,14,17} - not defined if -std=c++{98,11,14,17} why such difference? A library I try to cross-compile tests for WIN32 and

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

On 2017/10/12 17:14, Frédéric wrote: However, why does w64 treat differently -std=gnu++XX than -std=c++XX? This does not look consistent to me as WIN32 is not concerned by the standard. It is GCC that does that, not MinGW-w64. The standard does not treat `WIN32` particularly, but the rule is

Re: [Mingw-w64-public] [PATCH 3/3] headers: Remove accidental double semicolons

On 2017/9/6 13:14, Martin Storsjö wrote: Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/stdio.h | 2 +- mingw-w64-headers/ddk/include/ddk/wdm.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) These three patches look good to me. -- Best

Re: [Mingw-w64-public] Problems with using printf format specs with GCC 7

On 2017/9/13 0:15, Eli Zaretskii wrote: You'd need to disassemble (or at least check with nm) the object/function to find out if it's calling __mingw_printf or regular printf, seems like emacs is using %lld and %I64 in different places. %lld is used for intmax_t values, %I64d is used for

Re: [Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.

On 2017/9/27 20:21, Christer Solskogen wrote: On 08-May-17 12:32, Kai Tietz wrote: ok, please apply. Was this ever applied? It seem still to happen with latest 5.x branch. Jon would you please cherry-pick it to v5.x? Thanks. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.

On 2017/9/27 20:32, Liu Hao wrote: On 2017/9/27 20:21, Christer Solskogen wrote: On 08-May-17 12:32, Kai Tietz wrote: ok, please apply. Was this ever applied? It seem still to happen with latest 5.x branch. Jon would you please cherry-pick it to v5.x? Thanks. Eventually, SF is back

Re: [Mingw-w64-public] [PATCH] headers: Add casts in ua_wcs*chr in stralign.h

On 2017/8/25 19:09, 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/ C-style casts shall suffice. I don't see why we have to

Re: [Mingw-w64-public] _ftelli64 bug

On 2017/10/19 18:22, Mateusz Mikuła wrote: 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 MSVCR90 have been in the DLL hell for a decade so linking against

[Mingw-w64-public] [PATCH] stdio/mingw_wvfscanf.c: Fix segmentation fault when a char or, string format (without malloc option) is used, like, 72d60c1a06490ec5937e6c620956b167bf0bf329.

roblem in the original post no longer happens on i686 and x86_64. -- Best regards, LH_Mouse From c470391c15e8006c43bc8d3924d1ad44de94ed87 Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mo...@126.com> Date: Tue, 14 Nov 2017 10:16:24 +0800 Subject: [PATCH] stdio/mingw_wvfscanf.c: Fix segmentatio

Re: [Mingw-w64-public] Crash with Windows 7

On 2017/11/27 21:55, Jeremy Nicoll wrote: > On Mon, 27 Nov 2017, at 13:03, Ruben Van Boxem wrote: >> It would really helpful there were a backtrace of the crash, so we could >> pinpoint where the problem might lie. > > How does one capture one on Windows? > Compile all your source with `-ggdb`

[Mingw-w64-public] Definition of `wint_t` violates the standard

Dear all, Today I noticed that `wint_t` is a typedef of `unsigned short`. This is however non-conforming, as the C99 standard says it shall not be changed by default argument promotions. This can be noticed from the following program: ``` E:\Desktop>expand -t4 test.c #include #include int

Re: [Mingw-w64-public] [PATCH] crt: Add an ldexpl function for arm and arm64

On 2017/12/17 15:25, Martin Storsjö wrote: > Since long double just is normal double on arm and arm64, just > call the normal ldexp function. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/Makefile.am | 3 ++- > mingw-w64-crt/math/arm/ldexpl.c | 16

Re: [Mingw-w64-public] [PATCH] crt: Add linker aliases for utime/_utime/_futime/_wutime for ucrtbase

On 2017/12/19 20:13, Martin Storsjö wrote: > This matches what MSVC does. > > Signed-off-by: Martin Storsjö > --- > mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++ > mingw-w64-crt/lib-common/ucrtbase.def.in | 4 > 2 files changed, 6 insertions(+) > On my

Re: [Mingw-w64-public] [PATCHv2] crt: Add an ldexpl function for arm and arm64

On 2017/12/18 3:43, Martin Storsjö wrote: > Since long double just is normal double on arm and arm64, just > call the normal ldexp function. > > Signed-off-by: Martin Storsjö > --- > Fixed the parameters in the C wrappers. > --- > mingw-w64-crt/Makefile.am | 3 ++- >

Re: [Mingw-w64-public] [PATCH] crt: Add an ldexpl function for arm and arm64

On 2017/12/18 3:42, Martin Storsjö wrote: > Indeed - I'm amazed that this even compiled... > > // Martin C does not forbid /implicit conversion/ from a pointer to an integer... You probably need to enable `-Werror`. -- Best regards, LH_Mouse

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/11 21:47, Hannes Domani via Mingw-w64-public wrote: Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao <lh_mo...@126.com> Folgendes geschrieben: Debugging in assembly exposes indirection through a null pointer in `mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after li

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/13 11:11, David Lee wrote: Built and tested a cross compiler (i686-w64-mingw32-gcc 6.4.0) on debian stretch with master mingw-w64. Same crash. Yeah I just updated MSYS2's repos and observed the crash... can't imagine why it didn't crash a few days ago. The patch for

  1   2   3   4   5   6   7   8   9   10   >