Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

On 20.11.2022 18:58, Eli Zaretskii wrote: And if your application uses features unavailable in older (or default) crt versions then this make application code simplifier. Also redistributable packages are in most cases installed by Windows update mechanism, which could be marked as system library

Re: [Mingw-w64-public] Feature Request: Add IPackage2

On 29.08.2022 13:35, Luca Bacci wrote: Update: I now see that the structures are declared directly in GLib/GIO headers, https://gitlab.gnome.org/GNOME/glib/-/blob/2.73.3/gio/gwin32api-package.h. I wonder if it would be possible to add the declarations to mingw-w64 headers. If i remember correctl

Re: [Mingw-w64-public] _FILE_OFFSET_BITS + stat macro + conflicts

On 21.01.2022 17:32, Christoph Reiter wrote: when _FILE_OFFSET_BITS is defined (ideally Windows code shouldn't depend on it, but here we are) mingw-w64 does this: https://github.com/mingw-w64/mingw-w64/blob/898141aa957b99812f2f4d2cf89255798d578d54/mingw-w64-headers/crt/sys/stat.h#L279 This s

Re: [Mingw-w64-public] bug in sin(pi) ?

On 10.06.2021 10:03, Liu Hao wrote: 在 6/10/21 1:40 AM, Carl Kleffner 写道: This behaviour is described here: Intel Underestimates Error Bounds by 1.3 quintillion in great detail. A possible soluti

Re: [Mingw-w64-public] naming convention of mingw-w64 and compile Windows binary on MacOS

On 11.01.2021 17:07, Liu Hao wrote: 在 2021-01-10 23:46, Peng Yu 写道: I just want to know the basic of the compilation commands. I see these. $ i686-w64-mingw32-gcc main.c $ file a.exe a.exe: PE32 executable (console) Intel 80386, for MS Windows $ x86_64-w64-mingw32-gcc main.c $ file a.exe a.exe

Re: [Mingw-w64-public] naming convention of mingw-w64 and compile Windows binary on MacOS

On 10.01.2021 5:11, Peng Yu wrote: I see the following files installed by `brew install mingw-w64`. I don't quite understand what `i686-w64-mingw32` and `x86_64-w64-mingw32` means. Could anybody let me know? Welcome to the world of GNU. These are cpu-vendor-os triplets (yes, mingw32 is not an

Re: [Mingw-w64-public] IExtractIcon missing functions

On 07.01.2021 23:36, Biswapriyo Nath wrote: Do you have any project which requires those APIs declarations? It would be better to have a test project. I wrote a test program[0] for a GLib issue 2096 that uses this functionality. [0]: https://gitlab.gnome.org/GNOME/glib/-/issues/2096#note_99770

[Mingw-w64-public] IExtractIcon missing functions

Is it me, or are IUnknown functions missing from IExtractIconA and IExtractIconW Vtbls? OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/li

Re: [Mingw-w64-public] [PATCH 1/6] winpthreads: simplify the USE_VEH_FOR_MSC_SETTHREADNAME check

On 08.04.2020 18:13, Steve Lhomme wrote: > When compiling with other compilers than MSVC, we always use the code > relying on USE_VEH_FOR_MSC_SETTHREADNAME. > > -#if !defined(_MSC_VER) || defined (USE_VEH_FOR_MSC_SETTHREADNAME) > +#if !defined(_MSC_VER) > +#define USE_VEH_FOR_MSC_SETTHREADNAME > +

Re: [Mingw-w64-public] How do i use IAsyncOperation and AsyncActionCompletedHandler?

On 30.12.2019 9:46, Biswapriyo Nath wrote: > What do you want to do with that program? > Get a list of UWP applications available to the user that runs it. signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w

[Mingw-w64-public] How do i use IAsyncOperation and AsyncActionCompletedHandler?

I'm trying to get some info via COM, and i've got as far as getting an instance of IAsyncOperation. Now i need to wait for it to complete *somehow*, but it's unclear how to do it. All MS examples use some advanced C++ at the very least. I've tried to implement an AsyncActionCompletedHandler object

Re: [Mingw-w64-public] Building binutils with gcc 9.2.0

On 22.11.2019 19:22, Kacvinsky, Tom wrote: > I am seeing this while building bintutils 2.33.1 with gcc 9.2.0 that comes > with the wingw-w64-i686-toolchain > supplied compilers: > > ../../../libiberty/pex-unix.c:395:20: error: 'FD_CLOEXEC' undeclared (first > use in this function) > 395 |

[Mingw-w64-public] _FILE_OFFSET_BITS on 64-bit systems

The way i read _mingw_stat64.h and sys/stat.h, if _FILE_OFFSET_BITS is undefined (i.e. autotools is not being used) and the host architecture is x86_64, we end up with struct stat that has 32-bit st_size field, because _off_t is always 32-bit, and there's no macro to turn stat into _stat64, because

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 02.07.2019 14:58, Jacek Caban wrote: > On 7/2/19 1:35 PM, LRN wrote: >> On 02.07.2019 13:42, Jacek Caban wrote: >>> On 02/07/2019 12:38, LRN wrote: >>>> On 02.07.2019 13:15, Jacek Caban wrote: >>>>> On 02/07/2019 12:12, Jacek Caban wro

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 02.07.2019 15:14, Liu Hao wrote: > 在 2019/7/2 下午8:00, Jonathan Wakely 写道: >> The C++ standard says: >> >> "The library may reuse the value of a thread::id of a terminated >> thread that can no longer be joined." >> >> So that's not a reason to use a handle. > > According to MSDN [1] a thread ID

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 02.07.2019 13:42, Jacek Caban wrote: > > On 02/07/2019 12:38, LRN wrote: >> On 02.07.2019 13:15, Jacek Caban wrote: >>> On 02/07/2019 12:12, Jacek Caban wrote: >>>> On 02/07/2019 11:57, Liu Hao wrote: >>>> >>>>> 在 2019/7/2 下午5:19, Eri

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 02.07.2019 13:15, Jacek Caban wrote: > > On 02/07/2019 12:12, Jacek Caban wrote: >> On 02/07/2019 11:57, Liu Hao wrote: >> >>> 在 2019/7/2 下午5:19, Eric Botcazou 写道: > It seems inappropriate to use handles as thread identifiers (as > handles > imply resource ownership and are not uni

Re: [Mingw-w64-public] CRT uses POSIX functions.

On 01.06.2019 19:39, sotrdg sotrdg wrote: > Aren’t these “malloc”,”strlen”,”malloc” etc standard C functions? > My guess is that he means that on Windows the C runtime library dependency is not mandatory. Drivers and other kernel-level components are often written without using it. signature.a

Re: [Mingw-w64-public] Update OpenGL headers

On 10.05.2019 16:28, LRN wrote: > On 10.05.2019 15:53, NightStrike wrote: >> On Fri, May 10, 2019, 5:24 AM LRN wrote: >> >>> TBH, i'm starting to think that we should radically cut the GL headers >>> down and >>> only ship GL.h and GLU.h, just lik

Re: [Mingw-w64-public] Update OpenGL headers

On 10.05.2019 15:53, NightStrike wrote: > On Fri, May 10, 2019, 5:24 AM LRN wrote: > >> TBH, i'm starting to think that we should radically cut the GL headers >> down and >> only ship GL.h and GLU.h, just like MS does (and also glaux.h, probably). >> The

Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded

On 07.03.2019 11:26, Matthias Apitz wrote: > El día Wednesday, March 06, 2019 a las 11:20:05AM -0800, David Grayson > escribió: > >> Your experience matches mine: the Cygwin ldd utility does not work properly >> with MinGW DLLs and prints a bunch of question marks. There is an ntldd >> utility y

Re: [Mingw-w64-public] Getting actual import name from dynamic library

On 07.03.2019 10:11, Пётр Байкалов wrote: > How do I get the name of library which will be imported? For example, I > have "libopencv_phase_unwrapping.dll.a" , how do I get > "libopencv_phase_unwrapping320.dll" from it? dlltool -I libopencv_phase_unwrapping.dll.a signature.asc Description: Open

Re: [Mingw-w64-public] [PATCH 2/2] Ensure wait timeouts are respected

On 01.03.2019 17:19, Liu Hao wrote: > Wouldn't this be better, saving a call to `_pthread_get_tick_count()` ? > > > (the compound assignment operator seems incorrect). > New version is attached. From 0d93a97765716b5b642bf39663c5162af3f8ebf5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=A0=D1=83=

Re: [Mingw-w64-public] [PATCH 2/2] Ensure wait timeouts are respected

On 01.03.2019 17:19, Liu Hao wrote: > 在 2019/3/1 19:08, LRN 写道: >> New version is attached. >> > >> >> +result = WaitForMultipleObjects ((DWORD) count, (HANDLE *) handles, >> all, (DWORD) wait_time); >> +current_time = _pthread_get_tick_co

Re: [Mingw-w64-public] [PATCH 2/2] Ensure wait timeouts are respected

On 01.03.2019 9:13, Liu Hao wrote: > 在 2019/3/1 下午1:34, LRN 写道: >> On 01.03.2019 5:53, Liu Hao wrote: >> >> GetTickCount64() then, i guess? >> > > `GetTIckCount64()` for Vista and above or `QueryPerformanceCounter()` > for XP. I really don't care about XP

Re: [Mingw-w64-public] [PATCH 1/2] Round up when converting nanoseconds to milliseconds

On 01.03.2019 5:48, Liu Hao wrote: > 在 2019/3/1 上午2:09, LRN 写道: >> If the caller provides ts_nsec in struct timespec, >> we lose precision when converting that time to milliseconds >> for our WaitFor*() calls. Make sure we round *up* when doing that >> conversion, as o

Re: [Mingw-w64-public] Broken FreeAddrInfoEx in ws2tcpip.h

On 01.03.2019 10:14, Liu Hao wrote: > 在 2019/2/11 下午6:34, Liu Hao 写道: >> 在 2019/2/8 19:59, Liu Hao 写道: >>> 在 2019/2/8 上午4:41, LRN 写道: >>>> ws2tcpip.h declares: >>>> WINSOCK_API_LINKAGE void WSAAPI FreeAddrInfoExA(PADDRINFOEXA pAddrInfo); >>&g

Re: [Mingw-w64-public] [PATCH 2/2] Ensure wait timeouts are respected

On 01.03.2019 5:53, Liu Hao wrote: > 在 2019/3/1 上午2:09, LRN 写道: >> +unsigned long >> +_pthread_wait_for_single_object (void *handle, unsigned long timeout) >> +{ >> + DWORD result; >> + BOOL end_loop; >> + DWORD start_time = GetTickCount (); > > T

Re: [Mingw-w64-public] [PATCH 1/2] Round up when converting nanoseconds to milliseconds

On 01.03.2019 5:48, Liu Hao wrote: > 在 2019/3/1 上午2:09, LRN 写道: >> If the caller provides ts_nsec in struct timespec, >> we lose precision when converting that time to milliseconds >> for our WaitFor*() calls. Make sure we round *up* when doing that >> conversion, as o

[Mingw-w64-public] [PATCH 1/2] Round up when converting nanoseconds to milliseconds

If the caller provides ts_nsec in struct timespec, we lose precision when converting that time to milliseconds for our WaitFor*() calls. Make sure we round *up* when doing that conversion, as otherwise the wait time will be *less* than the caller expects. Users of pthreads on non-realtime systems a

[Mingw-w64-public] [PATCH 2/2] Ensure wait timeouts are respected

WaitFor*() functions may time out earlier than requested or later than requested. The "later" part is generally OK. The "earlier" part is not. Fix this by running the wait functions in a loop until the time actually runs out, or the function returns a non-timeout code. This does not apply to case

[Mingw-w64-public] Broken FreeAddrInfoEx in ws2tcpip.h

ws2tcpip.h declares: WINSOCK_API_LINKAGE void WSAAPI FreeAddrInfoExA(PADDRINFOEXA pAddrInfo); WINSOCK_API_LINKAGE void WSAAPI FreeAddrInfoExW(PADDRINFOEXW pAddrInfo); however of these two functions only the latter exists in ws2_32.dll. The former is actually named FreeAddrInfoEx, without the "A" s

Re: [Mingw-w64-public] 32-bit off_t on x86_64

On 04.08.2018 23:50, Gisle Vanem wrote: > LRN wrote: > >> We've got a complaint about crashes when using g_stat() in glib. Debugging >> showed that sizeof stat.st_size == 4 in user application, but sizeof stat >> st_size == 8 in glib. >> >> Turns ou

[Mingw-w64-public] 32-bit off_t on x86_64

We've got a complaint about crashes when using g_stat() in glib. Debugging showed that sizeof stat.st_size == 4 in user application, but sizeof stat st_size == 8 in glib. Turns out, MinGW-w64 defines 'off_t' (the type of st_size) as a synonym for 'long', and 'long' is always[1] 32-bit on Windows.

Re: [Mingw-w64-public] Error Codes Patch

On 02.08.2018 20:10, Tom Ritter wrote: > Hit an error compiling Firefox because 1471 wasn't defined. Add more context here because 1471 doesn't ring a bell. signature.asc Description: OpenPGP digital signature -- Check

[Mingw-w64-public] pthread_cond_timedwait_relative_np() returns too early in winpthreads

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's a testcase, compile with gcc -g -O2 pthreads_relwait.c -o pthreads_relwait.exe -lpthread The testcase should succeed (return 0), and print into the console that it waited for one second (or more). But when compiled against winpthreads it retu

Re: [Mingw-w64-public] [BUG (suspicious)] gdb crashes when info registers

On 01.05.2018 10:57, 章成凯 wrote: > source code of the program I debug, crash screenshot and some debug info > related to this crash are in the attachment. Looks like sourceforge ate your attachment, sorry to say. signature.asc Description: OpenPGP digital signature ---

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

On 9/12/2017 8:22 PM, Liu Hao wrote: > 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

Re: [Mingw-w64-public] DLL symbol decorations & gendef tool not distributed anymore

On 7/17/2017 1:21 PM, Martin Mitáš wrote: > The aim is to have > the DLL without the typical symbol suffix decorations (@num). > > Is there better way, how to achieve the goal without manual > maintaining of two .def files? Um...don't use stdcall? IIRC, the @X decorations only apply to stdcall

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

On 6/15/2017 7:47 AM, J. Peter Mugaas wrote: > ... I have made a a patch ... Forgot something? -- O< ascii ribbon - stop html email! - www.asciiribbon.org signature.asc Description: OpenPGP digital signature -- Check o

Re: [Mingw-w64-public] MinGW-w64 clock_gettime()

On 6/14/2017 10:33 PM, McLachlan, Donald (IC) wrote: > Hi, > > I was hoping to use clock_gettime(CLOCK_REALTIME, &ts) for high resolution > synchronized timestamps. But it appears the time reported is only updated > every system tick (~15.6 ms). Is this correct? > This is what git version of

Re: [Mingw-w64-public] Semi-OT: Is this sourceforge email legit? (Fwd: Important Account Information - Reconfirm Mailing List Subscriptions)

On 6/9/2017 6:13 AM, K. Frank wrote: > Hello List! > > I just wanted to check whether this email from sourceforge is legit. > It seemed a little odd -- out of the blue -- and sourceforge has earned > itself an imperfect reputation. > > Is this okay? Have others got this? > > > -- Forwa

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

On 6/3/2017 12:22 PM, bob by wrote: > > Can you please tell how large C programs usually organize memory? Bunch of > structures and globals I guess? Yes. C is not Rust, it doesn't have an intricate memory ownership model. You have chunks of memory and pointers to it. What you put there is up to y

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

On 6/2/2017 3:53 PM, bob by wrote: > On 2017-06-02 16:23 GMT+04:00 LRN wrote: >> On 6/2/2017 2:47 PM, bob by wrote: >>> Can somebody here write a replacement for the standard cout, that will be >>> able to print strings and integers, and internally will just redirect to

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

On 6/2/2017 2:47 PM, bob by wrote: > Can somebody here write a replacement for the standard cout, that will be > able to print strings and integers, and internally will just redirect to > puts and itoa? I'm only starting with C++, I'm not sure how to do it. I feel compelled to cite my own first ex

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

On 5/28/2017 9:53 PM, Edward Diener wrote: > On 5/28/2017 10:15 AM, niXman wrote: >> Edward Diener 2017-05-28 16:32: >>> As of September 2016, libbacktrace only supports ELF and PE/COFF >>> executables with DWARF debugging information. > > That does not seem very limiting. ELF and PE/COFF covers

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

On 5/28/2017 9:53 PM, Edward Diener wrote: > On 5/28/2017 10:15 AM, niXman wrote: >> Edward Diener 2017-05-28 16:32: >> >> >> [1] https://github.com/ianlancetaylor/libbacktrace > > Thanks for the link. > > How would I build this above-linked libbacktrace in mingw-64 for myself > ? Am I supposed

Re: [Mingw-w64-public] WinRT headers

On 07.01.2017 20:13, LRN wrote: > On 07.01.2017 6:06, LRN wrote: >> On 06.01.2017 18:46, Jacek Caban wrote: >>> On 1/6/17 4:34 PM, LRN wrote: >>>> On 06.01.2017 13:12, LRN wrote: >>>>> Managed to compile and use cecil, wrote a C# program that chur

Re: [Mingw-w64-public] WinRT headers

On 07.01.2017 6:06, LRN wrote: > On 06.01.2017 18:46, Jacek Caban wrote: >> On 1/6/17 4:34 PM, LRN wrote: >>> On 06.01.2017 13:12, LRN wrote: >>>> Managed to compile and use cecil, wrote a C# program that churns the data >>>> produced given by cecil and

Re: [Mingw-w64-public] [HELP] DLL relocation totally broken

On 07.01.2017 6:15, Linda Zhang wrote: > OS: Win7 SP1 > Toolchain: Mingw-w64 i686-6.2.0-release-win32-dwarf-rt_v5-rev1 > GCC: 4.8.x - 6.2.0 > Binutils: 2.21 - 2.25.1 > MinGW: official and w64, 4.x - 5.0.1 > Threading and except: all (dw2/sjlj/seh + win32/posix) > > Consider a dll whose base addres

Re: [Mingw-w64-public] WinRT headers

On 06.01.2017 18:46, Jacek Caban wrote: > On 1/6/17 4:34 PM, LRN wrote: >> On 06.01.2017 13:12, LRN wrote: >>> Managed to compile and use cecil, wrote a C# program that churns the data >>> produced given by cecil and outputs IDL files. Worked on it until the IDL >&g

Re: [Mingw-w64-public] WinRT headers

On 06.01.2017 13:12, LRN wrote: > Managed to compile and use cecil, wrote a C# program that churns the data > produced given by cecil and outputs IDL files. Worked on it until the IDL > files > it produced started to look legit. > > Then i fed an IDL file to a fresh (from m

Re: [Mingw-w64-public] WinRT headers

Managed to compile and use cecil, wrote a C# program that churns the data produced given by cecil and outputs IDL files. Worked on it until the IDL files it produced started to look legit. Then i fed an IDL file to a fresh (from mingw-w64-tools git) widl, and discovered that widl won't accept it.

Re: [Mingw-w64-public] WinRT headers

On 30.12.2016 19:18, LRN wrote: > Recently i've been thinking of using WinRT in C applications (GTK+, to be > specific). This is possible, because WinRT has COM interface, and COM is > usable > (with some verbosity) in C. > > fails to find one > crucial bit of informat

[Mingw-w64-public] WinRT headers

Recently i've been thinking of using WinRT in C applications (GTK+, to be specific). This is possible, because WinRT has COM interface, and COM is usable (with some verbosity) in C. Thing is, we need C headers for that. These could be written by hand or generated from idl files, and idl files coul

Re: [Mingw-w64-public] Test

On 11.11.2016 13:09, JonY wrote: > PGP/MIME signed message. > PGP/MIME signed messages rock. -- O< ascii ribbon - stop html email! - www.asciiribbon.org signature.asc Description: OpenPGP digital signature -- Develop

Re: [Mingw-w64-public] OpenGL headers need to be updated?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08.10.2016 12:48, Adrien Nader wrote: > On Thu, Aug 11, 2016, LRN wrote: >> On 10.08.2016 20:04, John Klimek wrote: >>> I'm trying to compile mpv which checks to see if the OpenGL >>> headers are installed. I

Re: [Mingw-w64-public] cause for 0xc0000005 fault@offset 0 in eventvwr

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10.09.2016 7:57, Jim Michaels wrote: > On 9/9/2016 5:45 PM, Jim Michaels wrote: >> I believe this to be caused by a runtime+stdc++ dll mismatch >> between compiler versions. >> >> verified. >> > to explain further, say you have an exe compiled w

Re: [Mingw-w64-public] problems with string combines in printf

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13.08.2016 18:54, Jim Michaels wrote: > void help(void) { printf("%s", PROGRAM_NAME " - " PROGRAM_DESCRIPTION > "\r\n" "usage: " PROGRAM_NAME " [options] [file1 file2] ...\r\n" > "options:\r\n" " [/?|-[-]?|-[-]h[elp]|/h[elp]] this help.\r\n" " >

Re: [Mingw-w64-public] OpenGL headers need to be updated?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10.08.2016 20:04, John Klimek wrote: > I'm trying to compile mpv which checks to see if the OpenGL headers > are installed. It's failing because the included 'gl.h' is missing > the constant GL_RGB32F. Instead, this is defined in glext.h. > > S

Re: [Mingw-w64-public] Error when cross compiling Cuba library with mingw-w64

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10.08.2016 1:48, Mosè Giordano wrote: > I'm trying to cross compile Cuba library > (http://www.feynarts.de/cuba/, here is the latest tarball: > http://www.feynarts.de/cuba/Cuba-4.2.tar.gz) for Windows on Linux > using mingw-w64, but I ran into

Re: [Mingw-w64-public] parallel make (make -j 4) and redirect problems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09.08.2016 10:57, Jim Michaels wrote: > nmake is not compatible with mingw-w64's make which is not compatible > with gnu make. If you're talking about i686-w64-mingw32-make.exe (or somesuch), then that is actually GNU make, just compiled for Wind

Re: [Mingw-w64-public] Does MinGW support Signals and sigset_t ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01.08.2016 15:05, LRN wrote: > On 01.08.2016 14:32, Jeffrey Walton wrote: >> On Mon, Aug 1, 2016 at 5:30 AM, LRN wrote: >>> On 01.08.2016 11:25, Jeffrey Walton wrote: >>> >>>> My question is, does MinGW sup

Re: [Mingw-w64-public] Does MinGW support Signals and sigset_t ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01.08.2016 14:32, Jeffrey Walton wrote: > On Mon, Aug 1, 2016 at 5:30 AM, LRN wrote: >> On 01.08.2016 11:25, Jeffrey Walton wrote: >> >>> My question is, does MinGW support Signals and sigset_t ? >> >> No. &g

Re: [Mingw-w64-public] Does MinGW support Signals and sigset_t ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01.08.2016 11:25, Jeffrey Walton wrote: > My question is, does MinGW support Signals and sigset_t ? No. > Or does MinGQW use SEH and try/except/finally? No. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNA

Re: [Mingw-w64-public] The compiler seems it can't recognize "%lld" and warns.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23.05.2016 12:52, 성이름 wrote: > Hi. I always appreciate your contribution. > > I use mingw-w64 5.3.0. > > In the case of: printf("%lld", longlongint); > > The compiler says: warning: unknown conversion type character 'l' in > format [-Wformat=]|

Re: [Mingw-w64-public] Hard-coded C++ paths and reloation problem on Windows

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28.04.2016 18:25, lh_mouse wrote: > I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on > Windows today. Now I have a relocation problem Is that a new problem (you've built gcc-5 and/or gcc-4 in MSYS2 with mingw-w64 CRT on Windows p

Re: [Mingw-w64-public] What to do when GMail marks list posts as spam

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01.04.2016 12:52, Ruben Van Boxem wrote: > On 2016-03-31 23:53 GMT+02:00 Jim Michaels wrote: >> I am seeing an example of ostream& operator<<(std::ostream& os, Loc& >> lc) that should work. did something change between now and 30 years >> ago? > S

Re: [Mingw-w64-public] why is g++ pasting the source code it compiles into the cmd shell?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27.04.2016 0:09, Jim Michaels wrote: > why is g++ pasting the source code it compiles into the cmd shell? > nasty action. Which version of g++? Which distribution of GCC (i.e. where did you get it from)? Does this depend on the code of the prog

Re: [Mingw-w64-public] [PATCH] Cast certain enums to int

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24.04.2016 14:55, LRN wrote: > On 24.04.2016 13:47, lh_mouse wrote: >> On 2016-04-24 18:36, LRN wrote: >>> On 24.04.2016 12:40, lh_mouse wrote: >>>> On 2016-04-23 03:38, LRN wrote: >>>>> On 22.04.2

Re: [Mingw-w64-public] [PATCH] Cast certain enums to int

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24.04.2016 13:47, lh_mouse wrote: > On 2016-04-24 18:36, LRN wrote: >> On 24.04.2016 12:40, lh_mouse wrote: >>> On 2016-04-23 03:38, LRN wrote: >>>> On 22.04.2016 20:24, LRN wrote: >>>>> This match

Re: [Mingw-w64-public] [PATCH] Cast certain enums to int

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24.04.2016 12:40, lh_mouse wrote: > On 2016-04-23 03:38, LRN wrote: >> On 22.04.2016 20:24, LRN wrote: >>> This matches the behaviour of MSVC better in cases when there is a >>> mix of values < 0 and values > 0

Re: [Mingw-w64-public] mingw-w64-public silently drops my posts

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23.04.2016 17:07, NightStrike wrote: > On Apr 22, 2016 1:24 PM, "LRN" wrote: >> This is a recent development. Last of my message that got through >> (apart from a couple of test messages that i've sent today)

Re: [Mingw-w64-public] [PATCH] Cast certain enums to int

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22.04.2016 20:24, LRN wrote: > This matches the behaviour of MSVC better in cases when there is a mix > of values < 0 and values > 0x7FFF in the same enum, which, without > this change, prompts GCC to increase enum size to 8 by

[Mingw-w64-public] Missing header: lowlevelmonitorconfigurationapi.h

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 lowlevelmonitorconfigurationapi.h is missing from mingw-w64-headers. It's a lowlevel counterpart of highlevelmonitorconfigurationapi.h and should have similar structure and dependencies. Please add it. - -- O< ascii ribbon - stop html email! - www

[Mingw-w64-public] [PATCH] Cast certain enums to int

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This matches the behaviour of MSVC better in cases when there is a mix of values < 0 and values > 0x7FFF in the same enum, which, without this change, prompts GCC to increase enum size to 8 bytes. Fixes bug #456 patch is attached - -- O< asci

[Mingw-w64-public] [PATCH] Check for ms_printf format and non-NULL format in MS printf

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 mingw-w64 ANSI printf has these checks, so why not MS printf? patch is attached P.S. This is an old patch that's been sitting in my toolchain for a year. I don't remember why i've added it, but it seems to not to break anything. - -- O< ascii rib

[Mingw-w64-public] mingw-w64-public silently drops my posts

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is a recent development. Last of my message that got through (apart from a couple of test messages that i've sent today) was: Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc on March 15. After some testing (thanks, lh_mouse) i've

[Mingw-w64-public] [PATCH] Add two missing prototypes to setupapi.h

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 patch is attached - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXGl3uAAoJEOs4Jb6SI2CwmKQH/jnjwqCQ/XOD5Il9cNNl825o QT3DoEXp/gNCYMa1Q6RsQiWrUeDdI9apvCyGm8DBIFgLgdfFObcq27

[Mingw-w64-public] yet another test mail

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ignore this if you see it, i'm checking whether my messages reach the mailing list. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXGlwwAAoJEOs4Jb6SI2Cw3PAIAMlnS+LSg02

[Mingw-w64-public] another test mail

Ignore this if you see it, i'm checking whether my messages reach the mailing list. -- O< ascii ribbon - stop html email! - www.asciiribbon.org -- Find and fix application performance issues faster with Applications Ma

Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc

On 17.03.2016 17:49, Gisle Vanem wrote: > > So how can I differentiate on your MinGW-w64 and TDM-gcc from > http://tdm-gcc.tdragon.net > Why would you do that? What are you hoping to achieve by telling the difference between TDM mingw-w64-based toolchain and non-TDM mingw-w64-based toolchain? -

Re: [Mingw-w64-public] profiling

On 26.01.2016 21:19, Victor Bombi wrote: > Hi, > > I am trying to profile a dll with gprof . The dll is compiled and linked > with -pg but the exe is not. When I start exe it gets stuck at the > beggining. > I have already look at > https://sourceware.org/binutils/docs-2.16/gprof/Compiling.html

Re: [Mingw-w64-public] winpthread and "leak"

On 30.12.2015 13:58, Vincent Torri wrote: > Hello > > With my little mem checker, i detect that winpthread does not free all > the resources it allocates. Is it normal ? > Does it leak continuously (more threads or other winpthreads objects -> more leaked memory), or just once? Leaking once is n

Re: [Mingw-w64-public] MingW w64 will support Vulkan?

On 25.12.2015 18:50, Alexey Solovey wrote: > Hello. Will you support of Vulkan API or not? I don't see anything about Vulkan on MSDN. Therefore, after one act of googling, i would assume that all vulkan-ish stuff comes from the Vulkan library supplied by the GPU driver, and MinGW only ever needs t

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

On 15.12.2015 14:05, Jacek Caban wrote: > Hi Vincent, > > On 12/15/15 7:20 AM, Vincent Torri wrote: >> Hello >> >> I am still working on Examine, my small valgrind-like memory leak >> detector (http://vtorri.github.io/examine/) and I have 2 questions. >> >> First, I recall that it works by doing D

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

On 15.12.2015 9:20, Vincent Torri wrote: > Hello > > I am still working on Examine, my small valgrind-like memory leak > detector (http://vtorri.github.io/examine/) and I have 2 questions. > > First, I recall that it works by doing DLL injection with > CreateRemoteThread, and API hooking by patch

Re: [Mingw-w64-public] [BUG REPORT]__mingw_printf doesn't handle "%a" correctly

On 22.10.2015 18:39, ntysdd wrote: > The "%a" specifier is new in C99, and it is supposed to print the > floating-point number in hexadecimal form. See http://sourceforge.net/p/mingw-w64/mailman/message/34544723/ -- O< ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Descr

Re: [Mingw-w64-public] wchar_t vs char

On 30.06.2015 19:44, p...@arbolone.ca wrote: > I have been reading that wchat_t, and therefore wstring, is neither UTF-8 nor > a UTF-16 character set. So, what is wstring good for then? Whether it's UTF-16 or UCS-2 depends on the implementation of the library that handles wstring. Sources, which

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote: > On 2015-06-22 17:21 GMT+02:00 LRN wrote: >> On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote: >>> Hi, >>> >>> Without eof, it still returns 262 bytes which is wrong. >> That's a very arbi

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote: > Hi, > > Without eof, it still returns 262 bytes which is wrong. That's a very arbitrary number. Is the file opened in binary mode? Anything significant around the 262th byte in the file contents? -- O< ascii ribbon - stop html email! - www.

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

On 21.06.2015 18:56, Edward Diener wrote: > On 6/21/2015 7:45 AM, LRN wrote: >> On 21.06.2015 5:44, John E. / TDM wrote: >>> On 6/20/2015 8:25 PM, Edward Diener wrote: >>>> Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64 >>>> in

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

On 21.06.2015 5:44, John E. / TDM wrote: > On 6/20/2015 8:25 PM, Edward Diener wrote: >> Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64 >> install now has gcc-5.1, but it has the same hardcoded to c:\mingw >> limitation which my OP is about. > > My experience in the past with

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

On 20.06.2015 19:21, Edward Diener wrote: > On 6/20/2015 10:50 AM, LRN wrote: >> On 20.06.2015 17:43, Edward Diener wrote: >>> Why does mingw-64, or the original mingw for that matter, consistently >>> hardcode include and lib search paths in their build for c:\mingw &

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

On 20.06.2015 17:43, Edward Diener wrote: > Why does mingw-64, or the original mingw for that matter, consistently > hardcode include and lib search paths in their build for c:\mingw > instead of searching for include files and libraries relative to its > installation structure ? This is a side

Re: [Mingw-w64-public] "Universal CRT" and Python support

On 19.05.2015 10:09, Ruben Van Boxem wrote: > Hi guys, > > There has recently (as in, yesterday) been a new flicker of activity in the > mingw-python camp. > For a long time, GCC on Windows was not a usable option for Python without > some pretty big workarounds and hacks to get everything working

Re: [Mingw-w64-public] building winpthreads dll fails when building cross compiler

On 08.05.2015 8:13, Luke Allardyce wrote: > When building winpthreads as part of a cross compiler I found that the > dll won't compile as the -no-pthread flag isn't passed to gcc > I remember something about giving gcc a fake pthread library to allow earlier stage to be built. Can't say anything

Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs

oesn't quite work as it is supposed to, building everything in one > shot, since the CRT depend on an already installed header set before it > can even compile. Likewise for the libraries. > > Kai? Ozkan? LRN? Any thoughts? No thoughts. I'm content with the way things are. If

Re: [Mingw-w64-public] Trouble cross-compiling SDL2

On 27.04.2015 20:37, Christer Solskogen wrote: > Hi! > > I've got trouble cross compiling SDL2 with the latest and greatest gcc, > binutils and mingw-w64. > > gcc version 5.1.0 (GCC) > GNU ld (GNU Binutils) 2.25 > and mingw-w64 v4.x (from git) > > I don't what is to blame. But I'm pretty sure t

[Mingw-w64-public] Re: AddClipboardFormatListener missing from libuser32.a

On 25.04.2015 10:04, Kai Tietz wrote: > 2015-04-25 6:41 GMT+02:00 LRN: >> On 24.04.2015 3:00, LRN wrote: >>> We have the prototype in the header (guarded as Vista-or-later), but no >>> stub in >>> the import library. I don't know how to fix that (.def file

  1   2   3   >