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

[LRN]

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. But
well, this is more license discussion than development discussion...


I mentioned that because people might inadvertently build GPL'ed GNU
software using this option, and violate the GPL without knowing it.  This is
relevant to those who read this list and port GNU software to MS-Windows.



Microsoft calls UCRT an "operating system component". UCRT comes pre-installed 
since Windows 10, updates via Windows Update, and can be installed after the 
fact on older versions of Windows (the ones still supported) via Windows 
Update. While i am not a lawyer, UCRT looks like a very uncontroversial case of 
a system library, and thus should fall under the "system library" exception of 
GPL, like MSVCRT.DLL does.


--
O< ascii ribbon - stop html email! - www.asciiribbon.org



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 correctly, i stubbed *a lot* of stuff when writing these headers, 
so they just *barely* cover glib's needs, with lots of void* and IUnknown in 
places of types that weren't interesting. Making a complete set of headers 
(with all the types correctly declared) by hand is a deep, deep rabbit hole 
that few people would crawl through on their own free will.


Ideally, these headers should be auto-generated from IDL files or from MS WINMD 
metadata blobs, but the existing tools (such as widl) couldn't t handle the 
corresponding IDL files back in 2020, and tools for making headers from WINMD 
didn't exist at all (i poked around Mono.Cecil, but writing a 100% correct 
parser-and-header-maker turned out to be too difficult for me).


--
O< ascii ribbon - stop html email! - www.asciiribbon.org

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

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

[LRN]

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 seems to be done on purpose, to transparently turn "stat" into a structure 
with 64-bit st_size and, possibly, 64-bit time fields. I think this is 
mentioned in https://www.msys2.org/wiki/Porting/



--
O< ascii ribbon - stop html email! - www.asciiribbon.org


OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 solution could be the usage of the SLEEF Vectorized Math Library
  (Boost Software License 1.0) which also supports
scalar trigonometric functions. There is no support for long double, but
for quad precision (FP128).




Before doing that, I would like to ask, does the inaccuracy really matter?


I always assumed that when dealing with floating-point math there's no such 
thing as "yielding precisely this number". You get something that is accurate 
to a certain point. If an implementation gives you something that is less 
accurate than other implementations, that's not good, but shouldn't have much 
influence on your calculations.


Why is this suddenly a concern?

--
O< ascii ribbon - stop html email! - www.asciiribbon.org



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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: PE32+ executable (console) x86-64, for MS Windows



You invoked `i686-w64-mingw32-gcc` on your machine (the 'host'), which produced 
a.exe suitable for
Windows on i686 (the 'target'). `x86_64-w64-mingw32-gcc` is similar.


Actually, if you want to be pedantic, his machine is 'build', and 'a.exe' is 
produced to be run on 'host'. The 'target' is only used for compilers (if 
'a.exe' is a compiler, then it would produce code for 'target', which might not 
be the same as 'build' and 'host').


--
O< ascii ribbon - stop html email! - www.asciiribbon.org



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 OS, welcome to the club) that identify the toolchain. i686 is 32-bit, 
x86_64 is 64-bit - that's all you need to now with regards to mingw. A bit more 
info can be found on the wiki[0], or just by googling.




If I want to compile windows binaries on Mac OS from the following .c
and .cpp files, could anybody let me know what commands I should use?


If you are _this_ inexperienced, consider using a build system. Meson[1] and 
CMake[2] are all the rage for C/C++ these days. A buildsystem will invoke the 
toolchain for you, no need to muck around with command lines.


[0]: https://sourceforge.net/p/mingw-w64/wiki2/TypeTriplets/
[1]: https://mesonbuild.com/SimpleStart.html
[2]: https://cmake.org/cmake/help/latest/guide/tutorial/index.html

--
O< ascii ribbon - stop html email! - www.asciiribbon.org



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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_997704

--
O< ascii ribbon - stop html email! - www.asciiribbon.org



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] IExtractIcon missing functions

[LRN]

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/lists/listinfo/mingw-w64-public

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

[LRN]

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
> +#endif
> +

I think the idea was to allow this code to be optionally used with MSVC
(nothing prevents it from working with MSVC, other than the fact that there's
an MSVC-specific alternative available).



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 myself, but the
program crashes when i call IAsyncOperation_put_Completed() with that object.

The program is attached.

I suspect that actually getting the handler invoked will require more work
(such as running a message pump), but i'll burn that bridge when i cross it.
#define INITGUID
#define COBJMACROS
#define _WIN32_WINNT 0x0602
#include 
#include 
#include 

#include 

typedef interface IPackageStatus IPackageStatus;

typedef interface IIterator IIterator;

typedef struct IIteratorVtbl {
BEGIN_INTERFACE

/*** IUnknown methods ***/
HRESULT (STDMETHODCALLTYPE *QueryInterface)(
IIterator *This,
REFIID riid,
void **ppvObject);

ULONG (STDMETHODCALLTYPE *AddRef)(
IIterator *This);

ULONG (STDMETHODCALLTYPE *Release)(
IIterator *This);

/*** IInspectable methods ***/
HRESULT (STDMETHODCALLTYPE *GetIids)(
IIterator *This,
UINT32 *count,
IID **ids);

HRESULT (STDMETHODCALLTYPE *GetRuntimeClassName)(
IIterator *This,
HSTRING *className);

HRESULT (STDMETHODCALLTYPE *GetTrustLevel)(
IIterator *This,
TrustLevel *trustLevel);

/*** IIterator methods ***/
HRESULT (STDMETHODCALLTYPE *get_Current)(
IIterator *This,
IUnknown **current);

HRESULT (STDMETHODCALLTYPE *get_HasCurrent)(
IIterator *This,
CHAR *hasCurrent);

HRESULT (STDMETHODCALLTYPE *MoveNext)(
IIterator *This,
CHAR *hasCurrent);

HRESULT (STDMETHODCALLTYPE *GetMany)(
IIterator *This,
UINT capacity,
void *value,
UINT *actual);

END_INTERFACE
} IIteratorVtbl;


interface IIterator {
CONST_VTBL IIteratorVtbl* lpVtbl;
};

/*** IUnknown methods ***/
#define IIterator_QueryInterface(This,riid,ppvObject) 
(This)->lpVtbl->QueryInterface(This,riid,ppvObject)
#define IIterator_AddRef(This) (This)->lpVtbl->AddRef(This)
#define IIterator_Release(This) (This)->lpVtbl->Release(This)
/*** IInspectable methods ***/
#define IIterator_GetIids(This,count,ids) 
(This)->lpVtbl->GetIids(This,count,ids)
#define IIterator_GetRuntimeClassName(This,name) 
(This)->lpVtbl->GetRuntimeClassName(This,name)
#define IIterator_GetTrustLevel(This,level) 
(This)->lpVtbl->GetTrustLevel(This,level)
/*** IIterator methods ***/
#define IIterator_get_Current(This,current) 
(This)->lpVtbl->get_Current(This,current)
#define IIterator_get_HasCurrent(This,hasCurrent) 
(This)->lpVtbl->get_HasCurrent(This,hasCurrent)
#define IIterator_MoveNext(This,hasCurrent) 
(This)->lpVtbl->MoveNext(This,hasCurrent)
#define IIterator_GetMany(This,capacity,value,actual) 
(This)->lpVtbl->GetMany(This,capacity,value,actual)

#define E_BOUNDS ((HRESULT)0x800BL)

typedef interface IIterable IIterable;

typedef struct IIterableVtbl {
BEGIN_INTERFACE

/*** IUnknown methods ***/
HRESULT (STDMETHODCALLTYPE *QueryInterface)(
IIterable *This,
REFIID riid,
void **ppvObject);

ULONG (STDMETHODCALLTYPE *AddRef)(
IIterable *This);

ULONG (STDMETHODCALLTYPE *Release)(
IIterable *This);

/*** IInspectable methods ***/
HRESULT (STDMETHODCALLTYPE *GetIids)(
IIterable *This,
UINT32 *count,
IID **ids);

HRESULT (STDMETHODCALLTYPE *GetRuntimeClassName)(
IIterable *This,
HSTRING *className);

HRESULT (STDMETHODCALLTYPE *GetTrustLevel)(
IIterable *This,
TrustLevel *trustLevel);

/*** IIterable methods ***/
HRESULT (STDMETHODCALLTYPE *First)(
IIterable *This,
IIterator **first);

END_INTERFACE
} IIterableVtbl;

interface IIterable {
CONST_VTBL IIterableVtbl* lpVtbl;
};

/*** IUnknown methods ***/
#define IIterable_QueryInterface(This,riid,ppvObject) 
(This)->lpVtbl->QueryInterface(This,riid,ppvObject)
#define IIterable_AddRef(This) (This)->lpVtbl->AddRef(This)
#define IIterable_Release(This) (This)->lpVtbl->Release(This)
/*** IInspectable methods ***/
#define IIterable_GetIids(This,count,ids) 
(This)->lpVtbl->GetIids(This,count,ids)
#define IIterable_GetRuntimeClassName(This,name) 
(This)->lpVtbl->GetRuntimeClassName(This,name)
#define IIterable_GetTrustLevel(This,level) 
(This)->lpVtbl->GetTrustLevel(This,level)
/*** IIterable methods ***/
#define IIterable_First(This,retval) (This)->lpVtbl->First(This,retval)

typedef interface IPackageManager IPackageManager;

DEFINE_GUID(IID_IPackageManager, 0x9A7D4B65, 0x5E8F, 0x4FC7, 0xA2, 0xE5, 0x7F, 
0x69, 0x25, 0xCB, 0x8B, 0x53);

typedef struct IPackageManagerVtbl {
BEGIN_INTERFACE

/*** IUnknown methods ***/
HRESULT (STDMETHODCALLTYPE *QueryInterface)(
IPackageManager *This,
   

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

[LRN]

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 |   if ((flags & FD_CLOEXEC) == 0 && fcntl (old_fd, F_SETFD, 
> FD_CLOEXEC) < 0)
>   |^~
> 
> This is even before I generate the mingw-64-headers.  I am going to try 
> downgrading binutils, but I don't
> think that Is an issue as I was able to build it with the x86_64 tool chain.  
> Could be the GCC tool chain I
> used for the x86_64 tool chain, which I think was GCC 9.1.
> 
> Any ideas
> 
This code shouldn't even be compiled in the first place. When building for W32,
pex-unix.c is not added the the source list. Verify that configure detects your
$host triplet correctly.



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 that macro only gets defined when _FILE_OFFSET_BITS is 64.

GNU docs say that _FILE_OFFSET_BITS should have no effect on 64-bit hosts, but
it is clearly not the case. So either the docs are wrong (i'm too , or
mingw-w64 LFS support is slightly broken. I've tested this on Debian x86_64,
and `struct stat` has 64-bit st_size field, even if _FILE_OFFSET_BITS is 
undefined.

The easiest way to fix this is probably to change sys/stat.h and ensure that
stat() is defined as _stat64 even if _FILE_OFFSET_BITS is undefined (but the
host is 64-bit).



signature.asc
Description: OpenPGP digital signature
___
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: [patch] Reimplement GNU threads library on native Windows

[LRN]

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 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 unique identifiers); thread
>>>>>>>>> IDs (as
>>>>>>>>> `DWORD` or `unsigned long`) would be a better alternative.
>>>>>>>> This was considered but ultimately rejected, as you can do nothing
>>>>>>>> with a
>>>>>>>> thread Id, i.e. you need a handle for everything.  But the
>>>>>>>> __gthread_equal
>>>>>>>> routine does compare the Ids and not the handles.
>>>>>>>>
>>>>>>> The `OpenThread()` function can obtain a handle by thread ID. It returns
>>>>>>> a real handle that has to be closed when it is out of use. Using the
>>>>>>> pseudo handle returned by `GetCurrentThread()` may be more efficient if
>>>>>>> the target thread ID is equal to `GetCurrentThreadId()`.
>>>>>> The problem with thread id is that it's not valid nor guaranteed to be
>>>>>> identical after the thread is terminated. A handle needs to be used
>>>>>> for that.
>>>>> I meant unique, not identical.
>>>>>
>>>> According to linux.die.net[0], Linux kernel re-uses thread IDs. This
>>>> stackoverflow answer[1] claims that this applies to all POSIX threads
>>>> implementations, citing opengroup spec[2].
>>>
>>> It will not reuse them until you detach or join the thread. Joining may
>>> happen after the thread is terminated.
>>>
>> It just means that you may not be able to use Windows thread IDs for that, 
>> but
>> using your own, homegrown thread IDs would be OK (just make sure an ID is 
>> valid
>> until a thread is joined or detached - that would usually imply keeping
>> metadata of a thread around after it's terminated).
> 
> 
> That would be additional complication with additional problems. Without 
> a handle, there is no reliable way to detect if thread is terminated and 
> if it's not, you need to wait in join. Also, you'd replace handle leak 
> to internal data leak.
> 
> 

So what you want is for the thread library to keep thread metadata around while
the thread exists, then destroy that metadata when the thread terminates
(preventing leaks), and still be able to respond to thread-API calls (such as
join()) made from other threads toward this (now terminated) thread? I don't
know W32 and POSIX thread APIs to judge whether this is actually doable that
way, regardless of whether thread IDs are handles or not.



signature.asc
Description: OpenPGP digital signature
___
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: [patch] Reimplement GNU threads library on native Windows

[LRN]

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 is valid 'until the thread has been
> terminated' so I presume a terminated but unclosed thread does not have
> a thread ID.
> 

Good point. In NT world, as long as a handle for a resource exists, the
resource itself also exists, even if it's in a state that makes it unusable.
Until a handle is explicitly closed, it remains valid. Until all handles to a
resource are closed, the resource exists.



signature.asc
Description: OpenPGP digital signature
___
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: [patch] Reimplement GNU threads library on native Windows

[LRN]

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, Eric Botcazou 写道:
>>>>>>> It seems inappropriate to use handles as thread identifiers (as
>>>>>>> handles
>>>>>>> imply resource ownership and are not unique identifiers); thread
>>>>>>> IDs (as
>>>>>>> `DWORD` or `unsigned long`) would be a better alternative.
>>>>>> This was considered but ultimately rejected, as you can do nothing
>>>>>> with a
>>>>>> thread Id, i.e. you need a handle for everything.  But the
>>>>>> __gthread_equal
>>>>>> routine does compare the Ids and not the handles.
>>>>>>
>>>>> The `OpenThread()` function can obtain a handle by thread ID. It returns
>>>>> a real handle that has to be closed when it is out of use. Using the
>>>>> pseudo handle returned by `GetCurrentThread()` may be more efficient if
>>>>> the target thread ID is equal to `GetCurrentThreadId()`.
>>>>
>>>> The problem with thread id is that it's not valid nor guaranteed to be
>>>> identical after the thread is terminated. A handle needs to be used
>>>> for that.
>>>
>>> I meant unique, not identical.
>>>
>> According to linux.die.net[0], Linux kernel re-uses thread IDs. This
>> stackoverflow answer[1] claims that this applies to all POSIX threads
>> implementations, citing opengroup spec[2].
> 
> 
> It will not reuse them until you detach or join the thread. Joining may 
> happen after the thread is terminated.
> 

It just means that you may not be able to use Windows thread IDs for that, but
using your own, homegrown thread IDs would be OK (just make sure an ID is valid
until a thread is joined or detached - that would usually imply keeping
metadata of a thread around after it's terminated).




signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 like MS does (and also glaux.h, probably).
>>> The
>>> rest can be installed separately.
>>>
>>> In case anyone still thinks that shipping a full set of OpenGL headers in
>>> MinGW-w64-headers is a good idea, here's the patch that updates the
>>> headers to
>>> a fresh git revision.
>>
>> Why remove them?
> 
> Because someone has to keep them up to date as long as they are part of
> mingw-w64-headers.
> 
> An analogy: if we pretend for a second that a small part of the Boost headers
> (that Boost authors do not edit) is documented to be mandatory for inclusion 
> in
> mingw-w64-headers, then shipping all GL headers is equivalent to shipping all
> Boost headers.
> 

So, it's been a week. Any other opinions? Does anyone want the patch to be 
pushed?



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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
>> rest can be installed separately.
>>
>> In case anyone still thinks that shipping a full set of OpenGL headers in
>> MinGW-w64-headers is a good idea, here's the patch that updates the
>> headers to
>> a fresh git revision.
>
> Why remove them?

Because someone has to keep them up to date as long as they are part of
mingw-w64-headers.

An analogy: if we pretend for a second that a small part of the Boost headers
(that Boost authors do not edit) is documented to be mandatory for inclusion in
mingw-w64-headers, then shipping all GL headers is equivalent to shipping all
Boost headers.



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 you can use instead.  If it's not on your path already, I'm not
>> sure the best way to obtain it.  I just use MSYS2, because it's basically a
>> fork of Cygwin that makes it easy to install MinGW compilers and all the
>> other open source utilities you would need to build software on Linux,
>> including ntldd.
> 
> David, thanks for your reply. Does this mean I could move to a Linux system
> with Mingw-w64 to produce the DLL for Windows there? This would be the first
> option as I do know less as nothing about Windows, but 30++ years about
> UNIX :-)
> 

You must have heard of cross-compilation in all these 30++ years.
Cross-compilation is less convenient than using MSYS (since you have to have
buildsystem support, and be careful not to grab non-cross tools), but if you
are the developer of the program(s) you are compiling, and know your way around
autotools (or whatver buildsystem you're using) then it's perfectly doable.

Though that's not what David meant. He meant using MSYS (MSYS2, specifically),
which is, basically, Cygwin with serial numbers filed
off a few small changes that allow developers to trivially mix
native (GCC and binutils, specifically) and non-native (bash and perl,
specifically, for autotools) programs on Windows for the purpose of compiling
native Windows stuff.

If you use Cygwin to build native Windows software, you're cross-compiling. So
unless you need to do testing or do something else that involves running the
stuff you compile right after you get it, there's no advantage in
cross-compiling in Cygwin, as opposed to cross-compiling from Debian or
somesuch (and even then, you can achieve that on Linux too, by using Wine, it's
just more work than running Cygwin on Windows).



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:55:08 +
Subject: [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 cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).

This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.

The timeout checker uses the coarse GetTickCount64() because it's fast
and doesn't wrap around every 49 days.
Though it might not be accurate enough, let's go with it first.

On pre-Vista systems QueryPerformanceCounter() is used instead.
---
 mingw-w64-libraries/winpthreads/src/cond.c   |   8 +--
 mingw-w64-libraries/winpthreads/src/misc.c   | 104 +++
 mingw-w64-libraries/winpthreads/src/misc.h   |   2 +
 mingw-w64-libraries/winpthreads/src/mutex.c  |   2 +-
 mingw-w64-libraries/winpthreads/src/thread.c |   4 +-
 5 files changed, 113 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/cond.c 
b/mingw-w64-libraries/winpthreads/src/cond.c
index 3754a56..368ee8a 100644
--- a/mingw-w64-libraries/winpthreads/src/cond.c
+++ b/mingw-w64-libraries/winpthreads/src/cond.c
@@ -598,7 +598,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   DWORD res, dt;
   if (nointerrupt == 1)
   {
-res = WaitForSingleObject(sema, timeout);
+res = _pthread_wait_for_single_object(sema, timeout);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
@@ -622,7 +622,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   if (maxH == 2)
   {
 redo:
-  res = WaitForMultipleObjects(maxH, arr, 0, timeout);
+  res = _pthread_wait_for_multiple_objects(maxH, arr, 0, timeout);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -655,7 +655,7 @@ redo:
   if (timeout == INFINITE)
   {
 do {
-  res = WaitForSingleObject(sema, 40);
+  res = _pthread_wait_for_single_object(sema, 40);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -684,7 +684,7 @@ redo:
   dt = 20;
   do {
 if (dt > timeout) dt = timeout;
-res = WaitForSingleObject(sema, dt);
+res = _pthread_wait_for_single_object(sema, dt);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index d8753f2..76b89d3 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -52,3 +52,107 @@ unsigned long long _pthread_rel_time_in_ms(const struct 
timespec *ts)
 return t1 - t2;
 }
 
+static unsigned long long
+_pthread_get_tick_count (long long *frequency)
+{
+#if defined (_WIN32_WINNT) && (_WIN32_WINNT >= _WIN32_WINNT_VISTA)
+  (void) frequency; /* unused */
+  return GetTickCount64 ();
+#else
+  LARGE_INTEGER freq, timestamp;
+
+  if (*frequency == 0)
+  {
+if (QueryPerformanceFrequency ())
+  *frequency = freq.QuadPart;
+else
+  *frequency = -1;
+  }
+
+  if (*frequency > 0 && QueryPerformanceCounter ())
+return timestamp.QuadPart / (*frequency / 1000);
+
+  /* Fallback */
+  return GetTickCount ();
+#endif
+}
+
+/* A wrapper around WaitForSingleObject() that ensures that
+ * the wait function does not time out before the time
+ * actually runs out. This is needed because WaitForSingleObject()
+ * might have poor accuracy, returning earlier than expected.
+ * On the other hand, returning a bit *later* than expected
+ * is acceptable in a preemptive multitasking environment.
+ */
+unsigned long
+_pthread_wait_for_single_object (void *handle, unsigned long timeout)
+{
+  DWORD result;
+  unsigned long long start_time, end_time;
+  unsigned long wait_time;
+  long long frequency = 0;
+
+  if (timeout == INFINITE || timeout == 0)
+return WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);
+
+  start_time = _pthread_get_tick_count ();
+  end_time = start_time + timeout;
+  wait_time = timeout;
+
+  do
+  {
+unsigned long long current_time;
+
+

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

[LRN]

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_count ();
>> +if (current_time >= end_time || result != WAIT_TIMEOUT)
>> +  break;
> 
> Wouldn't this be better, saving a call to `_pthread_get_tick_count()` ?
> 
> ```
> if (result != WAIT_TIMEOUT)
>   break;
> current_time = _pthread_get_tick_count ();
> if (current_time >= end_time)
>   break;
> ```

Yes, but i'm not sure which is more optimal - two if() checks vs a possibly
unneeded function call.
> 
>> +
>> +wait_time -= (DWORD) (end_time - current_time);
> 
> It looks like this should be
> 
> ```
> wait_time = (DWORD) (end_time - current_time);
> ```
> 
> (the compound assignment operator seems incorrect).
> 

ARGH. What is *wrong* with me?



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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, since MSYS2 has officially dropped
> XP support, but I think it might be configurable during build time by
> always using `uint64_t` for timestamps and call `GetTickCount()` or the
> 64-bit variant depending on the value of `_WIN32_WINNT`.
> 
> 

New version is attached.
From bc4c59a8ee9a709e1ced271c9fdcb2cc6c0ad466 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:55:08 +
Subject: [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 cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).

This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.

The timeout checker uses the coarse GetTickCount() because it's fast.
Though it might not be accurate enough, let's go with it first.
---
 mingw-w64-libraries/winpthreads/src/cond.c   |  8 +--
 mingw-w64-libraries/winpthreads/src/misc.c   | 98 
 mingw-w64-libraries/winpthreads/src/misc.h   |  2 +
 mingw-w64-libraries/winpthreads/src/mutex.c  |  2 +-
 mingw-w64-libraries/winpthreads/src/thread.c |  4 +-
 5 files changed, 107 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/cond.c 
b/mingw-w64-libraries/winpthreads/src/cond.c
index 3754a56..368ee8a 100644
--- a/mingw-w64-libraries/winpthreads/src/cond.c
+++ b/mingw-w64-libraries/winpthreads/src/cond.c
@@ -598,7 +598,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   DWORD res, dt;
   if (nointerrupt == 1)
   {
-res = WaitForSingleObject(sema, timeout);
+res = _pthread_wait_for_single_object(sema, timeout);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
@@ -622,7 +622,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   if (maxH == 2)
   {
 redo:
-  res = WaitForMultipleObjects(maxH, arr, 0, timeout);
+  res = _pthread_wait_for_multiple_objects(maxH, arr, 0, timeout);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -655,7 +655,7 @@ redo:
   if (timeout == INFINITE)
   {
 do {
-  res = WaitForSingleObject(sema, 40);
+  res = _pthread_wait_for_single_object(sema, 40);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -684,7 +684,7 @@ redo:
   dt = 20;
   do {
 if (dt > timeout) dt = timeout;
-res = WaitForSingleObject(sema, dt);
+res = _pthread_wait_for_single_object(sema, dt);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index d8753f2..c23f30f 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -52,3 +52,101 @@ unsigned long long _pthread_rel_time_in_ms(const struct 
timespec *ts)
 return t1 - t2;
 }
 
+static unsigned long long
+_pthread_get_tick_count (long long *frequency)
+{
+#if defined (_WIN32_WINNT) && (_WIN32_WINNT >= _WIN32_WINNT_VISTA)
+  (void) frequency; /* unused */
+  return GetTickCount64 ();
+#else
+  LARGE_INTEGER freq, timestamp;
+
+  if (*frequency == 0)
+  {
+if (QueryPerformanceFrequency ())
+  *frequency = freq.QuadPart;
+else
+  *frequency = -1;
+  }
+
+  if (*frequency > 0 && QueryPerformanceCounter ())
+return timestamp.QuadPart / (*frequency / 1000);
+
+  /* Fallback */
+  return GetTickCount ();
+#endif
+}
+
+/* A wrapper around WaitForSingleObject() that ensures that
+ * the wait function does not time out before the time
+ * actually runs out. This is needed because WaitForSingleObject()
+ * might have poor accuracy, returning earlier than expected.
+ * On the other hand, returning a bit *later* than expected
+ * is acceptable in a preemptive multitasking environment.
+ */
+unsigned long
+_pthread_wait_for_single_object (void *handle, unsigned long timeout)
+{
+  DWORD result;
+  unsigned long long start_time, end_time;
+  unsigned long 

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

[LRN]

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 otherwise the wait time will be *less* than the caller
>> expects. Users of pthreads on non-realtime systems are generally
>> OK with functions returning a bit later than requested. But timing out
>> *earlier* than the requested time is completely unexpected.
>> ---
>>  mingw-w64-libraries/winpthreads/src/misc.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>>
>>
> 
> This seems an overkill. There is a much simpler solution:
> 
> ```
> t += (unsigned long long) (ts->tv_nsec + 99) / 100;
> ```
> 
> 

New version is attached.
From 59fb104b98567fd4a56444daa4382e9e43279856 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:49:49 +
Subject: [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 are generally
OK with functions returning a bit later than requested. But timing out
*earlier* than the requested time is completely unexpected.
---
 mingw-w64-libraries/winpthreads/src/misc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index ab0488c..d8753f2 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -36,7 +36,8 @@ unsigned long long _pthread_time_in_ms(void)
 unsigned long long _pthread_time_in_ms_from_timespec(const struct timespec *ts)
 {
 unsigned long long t = (unsigned long long) ts->tv_sec * 1000LL;
-t += (unsigned long long) (ts->tv_nsec / 100);
+/* The +99 is here to ensure that the division always rounds up */
+t += (unsigned long long) (ts->tv_nsec + 99) / 100;
 
 return t;
 }
-- 
2.4.0



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 ();
> 
> There is no need to invoke `GetTickCount()` if `timeout` is `INFINITE`
> or zero.
> 
> Also I don't recommend use of `GetTickCount()` because its 32-bit return
> value would wrap round in approximately 49 days.

GetTickCount64() then, i guess?

> 
>> +
>> +  if (timeout == INFINITE || timeout == 0)
>> +return WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);
>> +
>> +  do
>> +  {
>> +result = WaitForSingleObject ((HANDLE) handle, (DWORD) timeout);
> 
> You have to recalculate `timeout` in this loop.

Ah, damn. Indeed.



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 otherwise the wait time will be *less* than the caller
>> expects. Users of pthreads on non-realtime systems are generally
>> OK with functions returning a bit later than requested. But timing out
>> *earlier* than the requested time is completely unexpected.
>> ---
>>  mingw-w64-libraries/winpthreads/src/misc.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>>
>>
> 
> This seems an overkill. There is a much simpler solution:
> 
> ```
> t += (unsigned long long) (ts->tv_nsec + 99) / 100;
> ```
> 
> 

I don't care how it works, as long as it works :)



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[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 otherwise the wait time will be *less* than the caller
expects. Users of pthreads on non-realtime systems are generally
OK with functions returning a bit later than requested. But timing out
*earlier* than the requested time is completely unexpected.
---
 mingw-w64-libraries/winpthreads/src/misc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

From 46ae81988f8ae040380816968f825a98af686def Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:49:49 +
Subject: [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 are generally
OK with functions returning a bit later than requested. But timing out
*earlier* than the requested time is completely unexpected.
---
 mingw-w64-libraries/winpthreads/src/misc.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index ab0488c..ddc5ab9 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -24,6 +24,9 @@
 #include "windows.h"
 #include "misc.h"
 
+#define NSEC_PER_SEC 10ULL
+#define NSEC_PER_MSEC   100ULL
+
 unsigned long long _pthread_time_in_ms(void)
 {
 FILETIME ft;
@@ -35,8 +38,16 @@ unsigned long long _pthread_time_in_ms(void)
 
 unsigned long long _pthread_time_in_ms_from_timespec(const struct timespec *ts)
 {
+unsigned long long t_ns;
 unsigned long long t = (unsigned long long) ts->tv_sec * 1000LL;
-t += (unsigned long long) (ts->tv_nsec / 100);
+t += (unsigned long long) (ts->tv_nsec / NSEC_PER_MSEC);
+
+t_ns = NSEC_PER_SEC * (unsigned long long) ts->tv_sec;
+t_ns += (unsigned long long) ts->tv_nsec;
+
+/* Round up when converting nanoseconds to milliseconds */
+if (t * NSEC_PER_MSEC < t_ns)
+  t += 1;
 
 return t;
 }
-- 
2.4.0



signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).

This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.

The timeout checker uses the coarse GetTickCount() because it's fast.
Though it might not be accurate enough, let's go with it first.
---
 mingw-w64-libraries/winpthreads/src/cond.c   |  8 ++---
 mingw-w64-libraries/winpthreads/src/misc.c   | 51 
 mingw-w64-libraries/winpthreads/src/misc.h   |  2 ++
 mingw-w64-libraries/winpthreads/src/mutex.c  |  2 +-
 mingw-w64-libraries/winpthreads/src/thread.c |  4 +--
 5 files changed, 60 insertions(+), 7 deletions(-)

From 8ef33231341c47ff6ca060e00c3c8be494a986b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Thu, 28 Feb 2019 17:55:08 +
Subject: [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 cases where timeout is 0 or INFINITE.
Those still use plain WaitFor*() calls (the wrappers, obviously,
still support these important corner-cases, but why call them
when we know that the timeout is 0 or INFINITE?).

This wouldn't have worked for handles that auto-reset
(i.e. where WaitFor*() call wakes up on handle activation, and immediately
resets the handle, preventing further WaitFor*() calls from waking up
until the handle is activated again), but winpthreads does not use those.

The timeout checker uses the coarse GetTickCount() because it's fast.
Though it might not be accurate enough, let's go with it first.
---
 mingw-w64-libraries/winpthreads/src/cond.c   |  8 ++---
 mingw-w64-libraries/winpthreads/src/misc.c   | 51 
 mingw-w64-libraries/winpthreads/src/misc.h   |  2 ++
 mingw-w64-libraries/winpthreads/src/mutex.c  |  2 +-
 mingw-w64-libraries/winpthreads/src/thread.c |  4 +--
 5 files changed, 60 insertions(+), 7 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/cond.c 
b/mingw-w64-libraries/winpthreads/src/cond.c
index 3754a56..368ee8a 100644
--- a/mingw-w64-libraries/winpthreads/src/cond.c
+++ b/mingw-w64-libraries/winpthreads/src/cond.c
@@ -598,7 +598,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   DWORD res, dt;
   if (nointerrupt == 1)
   {
-res = WaitForSingleObject(sema, timeout);
+res = _pthread_wait_for_single_object(sema, timeout);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
@@ -622,7 +622,7 @@ do_sema_b_wait_intern (HANDLE sema, int nointerrupt, DWORD 
timeout)
   if (maxH == 2)
   {
 redo:
-  res = WaitForMultipleObjects(maxH, arr, 0, timeout);
+  res = _pthread_wait_for_multiple_objects(maxH, arr, 0, timeout);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -655,7 +655,7 @@ redo:
   if (timeout == INFINITE)
   {
 do {
-  res = WaitForSingleObject(sema, 40);
+  res = _pthread_wait_for_single_object(sema, 40);
   switch (res) {
   case WAIT_TIMEOUT:
  r = ETIMEDOUT;
@@ -684,7 +684,7 @@ redo:
   dt = 20;
   do {
 if (dt > timeout) dt = timeout;
-res = WaitForSingleObject(sema, dt);
+res = _pthread_wait_for_single_object(sema, dt);
 switch (res) {
 case WAIT_TIMEOUT:
r = ETIMEDOUT;
diff --git a/mingw-w64-libraries/winpthreads/src/misc.c 
b/mingw-w64-libraries/winpthreads/src/misc.c
index ddc5ab9..13e309d 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -62,3 +62,54 @@ unsigned long long _pthread_rel_time_in_ms(const struct 
timespec *ts)
 return t1 - t2;
 }
 
+/* A wrapper around WaitForSingleObject() that ensures that
+ * the wait function does not time out before the time
+ * actually runs out. This is needed because WaitForSingleObject()
+ * might have poor accuracy, returning earlier than expected.
+ * On the other hand, returning a bit *later* than expected
+ * is acceptable in a preemptive multitasking environment.
+ */
+unsigned long
+_pthread_wait_for_single_object (void *handle, unsigned long 

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

[LRN]

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




signature.asc
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 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.
> 
> I imagined one had to compile using '-D_FILE_OFFSET_BITS=64' for this.

I can read the headers, thank you. I know that enabling LFS fixes that. What i
didn't know is that you need LFS or 64-bit st_size on 64-bit Windows - i
thought that LFS is a thing for 32-bit hosts, which need special header magic
to use 64-bit types in some places.

The need to use LFS to get 64-bit size_t - is that a Windows-specific deviation
from the usual convention of using 64-bit types on 64-bit platforms by default?



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] Error Codes Patch

[LRN]

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 out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 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] pthread_cond_timedwait_relative_np() returns too early in winpthreads

[LRN]

-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
returns early, usually a few milliseconds before the deadline (as measured by
QPC).

Tested on a fairly recent (a few months old) i686 mingw-w64 from MSYS2.

Just in case ML eats the attachment, here's the source code:

==pthreads_relwait.c=
#include 
#include 
#include 
#include 
#include 

#define USEC_PER_SEC 100

int func()
{
  LARGE_INTEGER freq;
  double usec_per_tick;
  LARGE_INTEGER ticks;

  if (!QueryPerformanceFrequency () || freq.QuadPart == 0)
return 1;

  usec_per_tick = (double) USEC_PER_SEC / freq.QuadPart;

  int64_t start;
  LARGE_INTEGER start_ticks;
  int64_t until;

  pthread_mutex_t mutex;

  if (pthread_mutex_init (, NULL) != 0)
return 2;

  pthread_condattr_t attr;
  pthread_cond_t cond;

  pthread_condattr_init ();

  if (pthread_cond_init (, ) != 0)
return 3;

  pthread_condattr_destroy ();

  if (!QueryPerformanceCounter ())
return 4;
  start = (int64_t) (ticks.QuadPart * usec_per_tick);
  start_ticks = ticks;
  until = start + 100 /* now + 1 second */;

  pthread_mutex_lock ();

  struct timespec ts;
  int status = 0;

  do
  {
int64_t now;
int64_t relative;

if (!QueryPerformanceCounter ())
  return 5;
now = (int64_t) (ticks.QuadPart * usec_per_tick);

if (until <= now)
  break;

relative = until - now;

ts.tv_sec = relative / 100;
ts.tv_nsec = (relative % 100) * 1000;

status = pthread_cond_timedwait_relative_np (,
 ,
 );

if (status != ETIMEDOUT && status != 0)
{
  printf ("status %d\n", status);
  return 6;
}

  } while (status == 0);

  int64_t after;
  LARGE_INTEGER after_ticks;

  if (!QueryPerformanceCounter ())
return 7;
  after = (int64_t) (ticks.QuadPart * usec_per_tick);
  after_ticks = ticks;

  pthread_mutex_unlock ();

  LARGE_INTEGER diff_ticks;
  diff_ticks.QuadPart = after_ticks.QuadPart - start_ticks.QuadPart;

  printf ("started at\n%lld\n"
  ", ended at\n%lld\n"
  ", aimed at\n%lld\n"
  ", difference is\n%lld\n",
  start, after, until, after - until);
  printf ("started at\n%lld ticks\n"
  ", ended at\n%lld ticks\n"
  ", difference is\n%lld ticks\n"
  ", with\n%lld ticks per second that is %f seconds)\n",
  start_ticks, after_ticks, diff_ticks.QuadPart,
  freq.QuadPart,
  (double) diff_ticks.QuadPart / (double) freq.QuadPart);

  if (after < until)
return 8;

  pthread_cond_destroy ();
  pthread_mutex_destroy ();
}

int
main (int argc, char **argv)
{
  int status = func ();
  if (status != 0)
printf ("Non-zero exit code %d\n", status);
  return 0;
}


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE4MWzR43wYaAzEA49ja3pJ2dZunQFAlsNw+kACgkQja3pJ2dZ
unQRqA//R9X4YmQBX1v4kZ4vzlGRQUWas4G+RJ/YRWLViFKWP35rcR0/2f6fEIV2
1hfzzL+P/SNXjKnLtaDmHmv1WfqJ1096WctLfivYjOFsmt5xMOrzNbzUUUEUykFr
gGe5pqE0VS/NYc1IY+un6walozuYSjkTid/9F/JbouD8lEg/niyQvbn7u9aoj14Q
ido4lMnnSP09o8/ZLVApEjSw+5jmqQlHPyrn+3yC59uLtDo9LErvqn1JAlA3eYWb
/gafYiDjQcE0dfxOad5t7K4Yc5iNyrcoE8zm2f+2/OxMnYF3CDd62ytJ7z6GHf/B
FLubl5vVQFYhOQoZtDm/HZtaPm+c47mjHpGinusk340alROvpUZItaIZLcuY0jF/
hosgezsaOaOhpMwg9/CfYXgjLtxtwbLEPBPxFOyWyGurSeOdg67BgRVWl8YY/kds
cqUDfQ0ViJ8d2yHAY05QGK8BX6fQq3pdDwS1SbPzoJwa9aF/oWsVQfVKAh2LPo0h
LUrEf5be71QS582QbWYegMRe428DvsBK+b2wBD/KbpHt9JipiEJqzbLUGk7iovsI
nk5AODNgq1eHh/A5yDIU5QKhOdTyBOoUU0XhqRgN8BDdYUnFWZzXgohKGv2+LVmf
eVUUfSoDQRuhL32tZcuA3XKe2Yd6LjywFqlYKBjUZznnNosyQ+4=
=b5fs
-END PGP SIGNATURE-
#include 
#include 
#include 
#include 
#include 

#define USEC_PER_SEC 100

int func()
{
  LARGE_INTEGER freq;
  double usec_per_tick;
  LARGE_INTEGER ticks;

  if (!QueryPerformanceFrequency () || freq.QuadPart == 0)
return 1;

  usec_per_tick = (double) USEC_PER_SEC / freq.QuadPart;

  int64_t start;
  LARGE_INTEGER start_ticks;
  int64_t until;

  pthread_mutex_t mutex;

  if (pthread_mutex_init (, NULL) != 0)
return 2;

  pthread_condattr_t attr;
  pthread_cond_t cond;

  pthread_condattr_init ();

  if (pthread_cond_init (, ) != 0)
return 3;

  pthread_condattr_destroy ();

  if (!QueryPerformanceCounter ())
return 4;
  start = (int64_t) (ticks.QuadPart * usec_per_tick);
  start_ticks = ticks;
  until = start + 100 /* now + 1 second */;

  pthread_mutex_lock ();

  struct timespec ts;
  int status = 0;

  do
  {
int64_t now;
int64_t relative;

if (!QueryPerformanceCounter ())
  return 5;
now = (int64_t) (ticks.QuadPart * usec_per_tick);

if (until <= now)
  break;

relative 

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

[LRN]

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
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 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] Problems with using printf format specs with GCC 7

[LRN]

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 is used for intmax_t values, %I64d is used for 64-bit values.
>>
>> Are you saying that MinGW64 doesn't support both %lld and %I64d?  If
>> so, under which conditions is each one supported?
>>
> 
> `printf()` provided by MSVCRT recognizes only `%I64d`, while 
> `__mingw_printf()` provided by MinGW-w64, which takes over `printf()` 
> due to `__USE_MINGW_ANSI_STDIO`, recognizes only `%lld`.

> This isn't related to the version of GCC, but to the version of 
> MinGW-w64 you have.
> 
These two things are orthogonal. GCC analyzes format strings and issues
warnings when they don't look right. print*() implementation (MSVCRT (without
MINGW_ANSI_STDIO), mingw (with MINGW_ANSI_STDIO), gnulib (when you use it), or
any other libc or utility library) analyzes format strings and expands the
field specifiers, producing the output. These two operate independently.

GCC looks at function attributes to get the idea what kind of formats it is
supposed to support.
"format (gnu_*printf, ...)" attributes support GNU formats.
"format (ms_*printf, ...)" attributes support MS formats.
"format (*printf, ...)" attributes are read as "ms_print*" when compiling for
Windows, and are read as "gnu_print*" when compiling for GNU.
What "GNU" and "MS" formats actually *mean* here (i.e. which kinds of
specifiers are valid or invalid) depends entirely on GCC.

Independently, actual print*() function implementations might support MS format
specifiers, or GNU format specifiers, or a mix of both (although it's usually
one or the other, with a bit of extras for compatibility in newer versions).

-- 
O< ascii ribbon - stop html email! - http://arc.pasp.de/


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] DLL symbol decorations & gendef tool not distributed anymore

[LRN]

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

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] mingw-w64-tools - configure.ac and Makefile.am for autoconf

[LRN]

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 out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 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 clock_gettime()

[LRN]

On 6/14/2017 10:33 PM, McLachlan, Donald (IC) wrote:
> Hi,
> 
> I was hoping to use clock_gettime(CLOCK_REALTIME, ) 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 winpthreads does in clock_gettime (not sure which
version is the latest in msys2):

case CLOCK_REALTIME:
{
GetSystemTimeAsFileTime();
t = ct.u64 - DELTA_EPOCH_IN_100NS;
tp->tv_sec = t / POW10_7;
tp->tv_nsec = ((int) (t % POW10_7)) * 100;

return 0;
}




-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] Semi-OT: Is this sourceforge email legit? (Fwd: Important Account Information - Reconfirm Mailing List Subscriptions)

[LRN]

On 6/9/2017 6:13 AM, K. Frank wrote:
> Hello List!
> 
> I just wanted to check whether this email from sourceforge is legit.
> It seemed a little odd -- out of the blue -- and sourceforge has earned
> itself an imperfect reputation.
> 
> Is this okay?  Have others got this?
> 
> 
> -- Forwarded message --
> From: SourceForge.net 
> Date: Thu, Jun 8, 2017 at 6:34 PM
> Subject: Important Account Information - Reconfirm Mailing List Subscriptions
> To: 

The message does mention reconfirmation via sourceforge.net website. So if you,
like me, mistrust the email, just log into your SF.net account and reconfirm 
there.


-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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

[LRN]

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 you, but
- yes, structures and arrays tend to dominate. Global variables are not
encouraged, for obvious reasons. There are some tricks, like slice allocators
(which allow faster-than-malloc allocations of small uniformly-sized chunks of
memory), but that's for special cases. Generally it's just heap and stack.

You'd have to be more specific to get a more precise answer.

> 
> Any programs whose source you'd recommend reading?

I would recommend reading books. Much easier to find pertinent information
there. Read the source code to learn what it does or how it does it, and to
make modifications. If you must read the source code, read the projects that
generate documentation from it - that usually forces people to be more
descriptive and add more comments. Also, if a project has some kind of style
guide and best practices list, that's a plus - the code will be easier to read,
and the list itself might point you at interesting stuff.
I can probably suggest you look at GSoC projects, as they had to accommodate
newcomers, and thus they should have some pertinent info laying around on their
websites and wikis.

> 
> Not sure if I should send questions like that in this mailing list, maybe I
> should ask directly.

Well, MinGW-w64-related questions would be more appropriate here. On the other
hand, people here *do* have some answers, so you might as well keep going,
unless someone points you towards the door.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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

[LRN]

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
>>> 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 experience with C++. Specifically, i
>> would like to mention that at the time i did not understand the difference
>> between C and C++. It took me a while to understand the difference and
>> realize
>> that the programs i was writing were really just C programs, even though i
>> was
>> compiling them with a C++ compiler. I stopped writing in C++ shortly
>> afterwards.
>>
>> I remembered that because you've mentioned cout and printf in the same
>> sentence.
>>
> 
> Do you use datatypes like linked lists or trees or hashmaps? Can you share
> some libraries or code to work with them?
> 
> I'm trying to learn C++ just because a lot of code I see is written in C++.
> Pretty much just in case.

glib[1] is the easiest for me to name. In my experience, large-ish C projects
tend to include their own (developed in-house or just copy-pasted from
somewhere) implementations of linked lists or trees when needed. Or use other
utility libraries (google for "C utility library") that complement the C
standard library, which is rather bare by itself.

If you want, you can google for "C vs C++". Also - look for articles on pros
and cons of object-oriented programming in general, and C++ (as an OOP
language) in particular. That might help you understand the current situation
around C++ better.

[1] https://en.wikipedia.org/wiki/GLib


-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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

[LRN]

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 experience with C++. Specifically, i
would like to mention that at the time i did not understand the difference
between C and C++. It took me a while to understand the difference and realize
that the programs i was writing were really just C programs, even though i was
compiling them with a C++ compiler. I stopped writing in C++ shortly afterwards.

I remembered that because you've mentioned cout and printf in the same sentence.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] Is there a libbacktrace library for mingw-64/gcc

[LRN]

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 all popular 
> object file formats on Linux and Windows respectively and surely just 
> about everyone not using VC++ uses DWARF rather than sjlj.
> 

I think there's some confusion here. ILT means DWARF /debug/ info[1] (the other
kind of debug info supported by GCC is STABS (there's also COFF, VMS and
variations, not our concern though); gcc uses DWARF by default, gdb understands
both), not DWARF (DW2) exception handling (where the other exception handling
mechanism is SJLJ, for 32-bit programs, and 64-bit programs have their own,
64-bit-specific exception handling).

[1] https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] Is there a libbacktrace library for mingw-64/gcc

[LRN]

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 to use the current mingw-64 build script to do so and 
> just copy the aforementioned 3 files to some final directories ?

* git clone https://github.com/ianlancetaylor/libbacktrace.git
* cd libbacktrace
* libtoolize -fi
* autoreconf -fi
* ./configure --prefix= --build=
--enable-host-shared
* make LDFLAGS="-no-undefined"
* make install DESTDIR=

The conventional prefix usually looks like "/mingw" or something like that. Do
"ls /" look for a similarly-named directory.
The build triplet is usually either i686-w64-mingw32 or x86_64-w64-mingw32,
depending on whether the program you're building is 32-bit or 64-bit.

Obviously, this is just a manual build routine, normally someone should can it
and then use buildscripts to build the package.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] WinRT headers

[LRN]

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 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. Fed an IDL file from 
>>>>> mingw-w64-headers
>>>>> git to the same widl, and discovered that widl does not accept that one 
>>>>> either.
>>>>>
>>>>> What am i doing wrong?
>>>>> The error (for mingw-w64-headers/windows.foundation.idl) is:
>>>>>
>>>>> Windows.Foundation.idl:14: error: syntax error, unexpected aIDENTIFIER,
>>>>> expecting $end
>>>>>
>>>> Poked widl a bit. It seems to be that the parser is broken, as it always 
>>>> bails
>>>> on any mention of "namespace {...}". Yacc source files do contain mentions 
>>>> of
>>>> namespaces, so obviously the parser used to support them somehow.
>>>>
>>>
>>> It may be worth trying plain Wine version of widl. I implemented some of 
>>> winrt features there, including partial support for namespaces. Sadly, 
>>> I'm sure that any complex IDL will hit its limitations. It's at least 
>>> good enough to properly handle simple IDLs like [1].
>>>
>>> mingw-w64 versions have some changes that were never upstreamed to Wine, 
>>> so merging that work may be tricky. We may worry about that once Wine 
>>> implementation is more useful.
>>>
>>
>> Another alternative exists: don't use widl at all, just generate c/c++ 
>> headers
>> directly from metadata. I'm not entirely sure how difficult/easy that would 
>> be.
>>
> 
> Spent 30 minutes merging all upstream widl commits into my mingw-w64-tools
> version of widl.
> Then spent two hours fighting with automake + flex + bison, because wine widl
> wasn't written with automake in mind.
> Finally compiled it (found a few minor merge errors where patches applied, but
> provided duplicate code).
> 
> Doesn't work (bails at typedef enum Blah { ... } Blah;)
> 
> Debugging suggests a parser error (the last "Blah;" is misclassified somehow),
> but i could be wrong.
> 
> Next stop is to try to just use 100% upstream widl instead.
> 

Compiled upstream widl. Same problem. Dug a bit more. AFAICS, it takes in the
typedef foo bar { ... } baz; constructs well enough - as long as they are not
inside a namespace. If they are, it just throws the "type bar is not found".
It is possible to rewrite IDL files completely without typedefs (i.e. use "enum
AsyncStatus" instead of "AsyncStatus" every time the type is used), but it's
cumbersome, IMO.

I'll look at generating headers directly from metadata. That is bound to be
easier (famous last words...).

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] WinRT headers

[LRN]

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 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. Fed an IDL file from 
>>>> mingw-w64-headers
>>>> git to the same widl, and discovered that widl does not accept that one 
>>>> either.
>>>>
>>>> What am i doing wrong?
>>>> The error (for mingw-w64-headers/windows.foundation.idl) is:
>>>>
>>>> Windows.Foundation.idl:14: error: syntax error, unexpected aIDENTIFIER,
>>>> expecting $end
>>>>
>>> Poked widl a bit. It seems to be that the parser is broken, as it always 
>>> bails
>>> on any mention of "namespace {...}". Yacc source files do contain mentions 
>>> of
>>> namespaces, so obviously the parser used to support them somehow.
>>>
>>
>> It may be worth trying plain Wine version of widl. I implemented some of 
>> winrt features there, including partial support for namespaces. Sadly, 
>> I'm sure that any complex IDL will hit its limitations. It's at least 
>> good enough to properly handle simple IDLs like [1].
>>
>> mingw-w64 versions have some changes that were never upstreamed to Wine, 
>> so merging that work may be tricky. We may worry about that once Wine 
>> implementation is more useful.
>>
> 
> Another alternative exists: don't use widl at all, just generate c/c++ headers
> directly from metadata. I'm not entirely sure how difficult/easy that would 
> be.
> 

Spent 30 minutes merging all upstream widl commits into my mingw-w64-tools
version of widl.
Then spent two hours fighting with automake + flex + bison, because wine widl
wasn't written with automake in mind.
Finally compiled it (found a few minor merge errors where patches applied, but
provided duplicate code).

Doesn't work (bails at typedef enum Blah { ... } Blah;)

Debugging suggests a parser error (the last "Blah;" is misclassified somehow),
but i could be wrong.

Next stop is to try to just use 100% upstream widl instead.

If that doesn't work, i'll look at just generating headers directly from
metaidlgen. AFAIU, actual header generation is just 1.7k LOC in header.c, the
real gnarly code is in IDL parsing, which metaidlgen doesn't need to do, as it
already has access to the full type hierarchy.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] [HELP] DLL relocation totally broken

[LRN]

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 address is overlapped with an existing module, so 
> that the operating system must relocate it, or for another word, rebase it, 
> to work. Relocation is the fundamental part of the security feature ASLR and 
> is enabled by default since Windows Vista. When ASLR is enabled, all 
> executables are relocated.
> 
> BUT, After relocation, the compiled DLL fails to load at all. That's to say, 
> the compiled DLL is broken.
> 

Works for me with this makefile:
===
all: test.dll test.exe
clean:
rm test.exe test.dll libtest.a
test.exe: testexe.c
gcc -o $@ $^ libtest.a -Wl,--image-base,0x40
test.dll: testdll.c
gcc -shared -o $@ $^ --def test.def -Wl,--out-implib -Wl,libtest.a
-Wl,--image-base,0x40
===

To confirm that they have the same image base:
$ objdump -x test.dll test.exe | grep image_base
[885](sec -1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0040 __image_base__
[1187](sec -1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0040 __image_base__

I've also added a pause to the executable and looked at the process at runtime,
and the test.dll is relocated as expected.

I would also like to note that i have no idea what "dllwrap" is. I see that
it's part of binutils, but i've never seen it being used. Its manpage says that
it is deprecated.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] WinRT headers

[LRN]

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 
>>> 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. Fed an IDL file from mingw-w64-headers
>>> git to the same widl, and discovered that widl does not accept that one 
>>> either.
>>>
>>> What am i doing wrong?
>>> The error (for mingw-w64-headers/windows.foundation.idl) is:
>>>
>>> Windows.Foundation.idl:14: error: syntax error, unexpected aIDENTIFIER,
>>> expecting $end
>>>
>> Poked widl a bit. It seems to be that the parser is broken, as it always 
>> bails
>> on any mention of "namespace {...}". Yacc source files do contain mentions of
>> namespaces, so obviously the parser used to support them somehow.
>>
> 
> It may be worth trying plain Wine version of widl. I implemented some of 
> winrt features there, including partial support for namespaces. Sadly, 
> I'm sure that any complex IDL will hit its limitations. It's at least 
> good enough to properly handle simple IDLs like [1].
> 
> mingw-w64 versions have some changes that were never upstreamed to Wine, 
> so merging that work may be tricky. We may worry about that once Wine 
> implementation is more useful.
> 

Another alternative exists: don't use widl at all, just generate c/c++ headers
directly from metadata. I'm not entirely sure how difficult/easy that would be.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] WinRT headers

[LRN]

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 mingw-w64-tools git) widl, and
> discovered that widl won't accept it. Fed an IDL file from mingw-w64-headers
> git to the same widl, and discovered that widl does not accept that one 
> either.
> 
> What am i doing wrong?
> The error (for mingw-w64-headers/windows.foundation.idl) is:
> 
> Windows.Foundation.idl:14: error: syntax error, unexpected aIDENTIFIER,
> expecting $end
> 

Poked widl a bit. It seems to be that the parser is broken, as it always bails
on any mention of "namespace {...}". Yacc source files do contain mentions of
namespaces, so obviously the parser used to support them somehow.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] WinRT headers

[LRN]

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 information - names for overloaded functions.
> 
> For example, Windows.UI.Core.CoreDispatcher has two methods: ShouldYield and
> ShouldYield. Name's the same. The difference is that first one takes no extra
> arguments, while second one gets an argument of type
> Windows.UI.Core.CoreDispatcherPriority.
> 
> In C, since it does not supports overloads, these two must have different
> names. Peeking at MS SDK idl files (or just grepping through Windows binaries)
> gives us the names - ShouldYield and ShouldYieldToPriority. Note that
> ShouldYieldToPriority is not documented anywhere (and gives almost literally
> zero results in Google), and is only ever mentioned in winmd files (and MS 
> SDK,
> of course).
> 
> So the first obstacle, i think, is to somehow make mono disassembler able to
> find these names for these overloaded functions in metadata files. 

After extensive googling i've found the RoGetMetaDataFile() function[1], which
can be given class name to obtain a COM object that implements IMetaDataImport2
interface[2][3]. According to this SO question[4], it is possible to use
IMetaDataImport to obtain the alternative names for overloaded functions (and
everything else that we might need to write an IDL).


[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/br229856(v=vs.85).aspx

[2] 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh870577(v=vs.85).aspx

[3] 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh870578(v=vs.85).aspx

[4]
https://stackoverflow.com/questions/12901855/winrt-idl-overload-reflection-through-imetadataimport

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] WinRT headers

[LRN]

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 could be written by hand or generated
from reading WinRT metadata.

I've considered the written-by-hand route, and it's tiresome. Methods often use
objects of other classes as arguments, which expands total number of classes
one needs to describe to do something useful. Also, documentation is scarce
(MSDN documents WinRT itself, but not its COM underbelly).

Using metadata seems like a more rational route, and it's possible too, because
WinRT is CLI-compatible, and exposes CLI metadata. We just need to be able to
read it.

I was able to successfully get some of that information from winmd files that
come with the OS by using the monodis program from Mono, but apart from some
weirdness (like not being able to load other assemblies; it's probably due to
me not using it correctly), and version mismatches, it fails to find one
crucial bit of information - names for overloaded functions.

For example, Windows.UI.Core.CoreDispatcher has two methods: ShouldYield and
ShouldYield. Name's the same. The difference is that first one takes no extra
arguments, while second one gets an argument of type
Windows.UI.Core.CoreDispatcherPriority.

In C, since it does not supports overloads, these two must have different
names. Peeking at MS SDK idl files (or just grepping through Windows binaries)
gives us the names - ShouldYield and ShouldYieldToPriority. Note that
ShouldYieldToPriority is not documented anywhere (and gives almost literally
zero results in Google), and is only ever mentioned in winmd files (and MS SDK,
of course).

So the first obstacle, i think, is to somehow make mono disassembler able to
find these names for these overloaded functions in metadata files. Do we have
any contacts with Mono or Cecil (the library that Mono uses to inspect
metadata, AFAIU) developers?

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org


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] Test

[LRN]

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
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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.  It's failing because the included 'gl.h'
>>> is missing the constant GL_RGB32F.  Instead, this is defined in
>>> glext.h.
>>> 
>>> Somebody from the mpv team said that this constant is now part of
>>> the default OpenGL specification so it should be defined in
>>> 'gl.h'.
>> 
>> If that constant is in glext.h, then that is where it is supposed to
>> be. I've pulled latest OpenGL registry svn revision (r33080 from
>> 2016-08-05) and that constant is still only in glext.h and
>> glcorearb.h.
>> 
>> If that is incorrect, complain to OpenGL registry[1] maintainers.
>> 
>>> 
>>> Does anybody know if the included OpenGL headers are recent or if
>>> they could be updated?
>> 
>> Most headers are from 2014-08-11 or so. They can be updated from
>> the OpenGL svn repo[2].
>> 
>> Previously i've been doing the updating. However, i have certain 
>> rudimentary quality control procedure for verifying that the headers
>> i've pulled are at least somewhat useful, and i put headers through
>> that procedure before pushing the update upstream. That procedure is
>> currently unavailable to me. That is why headers are 2 years old
>> now.
>> 
>> [1] https://www.opengl.org/registry/ [2]
>> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api
> 
> I got late in my handling of emails and I only recently read this. Is 
> there still a need or will for an update to more recent headers?
> 
> Can that test procedure be shared and properly run by someone else
> and is there someone interested to do that?
> 

The procedure is not secret. I just do a complete, clean rebuild of ~200
MinGW packages with the new headers. Some of these packages (SDL,
GStreamer, GTK+) make use of OpenGL. If all packages compile without
problems, i judge the headers fit for pushing into master.

I haven't updated my packages for almost 2 years now, so no rebuilds ->
no OpenGL header updates.

You can probably do something similar with MSYS2 or any other package
system. Just update the headers and rebuild everything.

Packages that use GL:
glew
freeglut
gst-plugins-bad (the gl plugin)
opencv
tiff (the tiffgt program)
webp (vwebp program)
gtk+ (gtk3-demo program, OpenGL demo)
SDL (though it's possible for GL parts to not to be built, i guess)

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJX+OrhAAoJEI2t6SdnWbp0I30P/ji8YWPgOPHi2G5PQ+WBW7FF
wiyXtUevtmAEjHtPG6/W2Fg5QJLWwNAZh1Els5pghEvAUnFTnWth58hhzt/Svfpu
QYa93zOFaXschPrsj9hwkupKuMwMIpWTTwpl33SjMulzF1BXVXQffG5geAbI/ADX
awFiZb3AEEeLf15bhAhh78CJ2OtchKcDEbdRZHpu5pxLNIpcyWlZKr0xeAJnhsbp
BdakOwH++VodOrm8C0ABramGb1AnEkk7q9rurWiMoYXiOBo53emRWUCqaeA242Rc
EJj5U4nGovcABC5d+4ZlhUIshNFGBtJ6ansWu3lb93pAA5MQpS4c2xQu3ncUELHT
Hl2oONhuIuYztNV78GQnutO49agoT2+7m/xoT10gAOaO0xNb1DsssZmvizYXM52u
hRRxyF1dVs190bqhR98X7b/g2BCbsWSVto4eV3XGWMhSCi7FNKY+nLE0OFZdw7Kq
xHlvMmZpHhiELUmiis/QxB5Ay+NnHKl43yA7V/N5vvzqWCNNdNgIVFQnnbcMCCIz
96xn/ICFU0Pryf4DhBkGQCepi2cvPVM2SYn1J3oHIms4/dUQ5mXUrNc5bNXwFZCs
QWI/j8Dc9tE95sttaEDYfuNO44S5zkoFkywV2ucl9zyKD1Jg9B6nvioibaTfeZJf
qbdBiqkWEaunD4GlVxoc
=Vrs0
-END PGP 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] cause for 0xc0000005 fault@offset 0 in eventvwr

[LRN]

-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 with 4.9.0 and you
> copy the dll's and EXE into \utils\ which is in your PATH.
> 
> but then afterwards with compiler version 5.0.0 you copy the exe only
>  into the same dir (mixup during process of going to static linking).
> 
> now try to run the exe. it will GPF/abend/core dump because it is 
> loading older dlls with an exe compiled with a newer compiler.
> 
> if the exe were statically linked, this solves the problem. so does 
> copying the dlls with the exe every time. but if you do the latter,
> you endanger older code.

I thought incompatible DLLs have different interface versions to ensure
that they are not mixed up.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJX05eZAAoJEI2t6SdnWbp09+wP/2iZqRHGB3jxond0Rd25kHND
lL4JhIyquYVUYA9B+e7xJ9OTtKWXDYV4Y2MWI4YXa9YmBYz4Al5yxUBBMLEJZcmr
MQs6c8hG6MBunIZ5BUGWZUtxS3kICyBQRnGgvcwWQsGoOBTq+L79ljBWbnQTmnK2
o7FgvxKruiNNHcnd5B+qutqVCk20MXdveriuEMyzetY0fyKXeW1EXObcmz7Pje7v
8YJG+/PZXy7PQaIST7g1ZJOMhjMnhDSwDm+Ujt9ToJcXCcWQK5iynOZlU6grburA
lhjrddswFIkXRJ8CPYcTqxPK5sx/gYewmkTChAC1SHDntkyMywgO+JwTFt9yFHDK
57y7z26+8t++K89h8ZD3VwonDy3YlqAnXYTXkEEZCPqg1Ye8FuVoYGdU2pU1iCy+
TugFoy9hoYD/n2kYqQfmbyLBlOYBHqoy+MGewlJxk+DJxC2MwD42gUsgPbp9Ez5X
StHtSUAEGG/vhRZ9hYzwY+OHSucEPECrKSi7t5irRflflSKwB/BaXuGHVHqwJyLF
hVhZaoaI4qnCvIgEvma56UMXr1C0ib7Ah4xX0aanWTRAS1gkOB8i0hqpBpsUvvje
cvAYEdf37UC2Fb5gXgf6X/J/eR3q6LCVQDOy4wpkeXj8oLgkXYfO81xhVv1RE0Ho
WIiBnKU6FvhnvqRoskm9
=cJaD
-END PGP SIGNATURE-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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" "
> [/version|-[-]version] gives version number.\r\n" "
> [/license|-[-]license] gives license.\r\n" "  file1 file to compare
> with.\r\n" "  file2 file to compare file1 against.\r\n" "if both files
> are equal of content, then ERRORLEVEL is 0 else ERRORLEVEL is 1.\r\n" 
> ); }
> 
> 
> # 18 "compare.cpp" void help(void) { printf("%s", "compare" " - "
> PROGRAM_DESCRIPTION "\r\n" "usage: " "compare" " [options] [file1
> file2] ...\r\n" "options:\r\n" "  [/?|-[-]?|-[-]h[elp]|/h[elp]] this
> help.\r\n" "  [/version|-[-]version] gives version number.\r\n" "
> [/license|-[-]license] gives license.\r\n" "  file1 file to compare
> with.\r\n" "  file2 file to compare file1 against.\r\n" "if both files
> are equal of content, then ERRORLEVEL is 0 else ERRORLEVEL is 1.\r\n" 
> ); }
> 
> Sat 08/13/2016 
> 8:32:05.20|C:\Users\Kristina\Desktop\prj\compare\1.0\win|>g++ -static
>  -save-temps -g -Xlinker compare.map  -lstdc++ -std=c++11 -o
> 32\compar e.exe compare.cpp compare.cpp: In function 'void help()': 
> compare.cpp:20:18: error: expected ')' before 'PROGRAM_DESCRIPTION' 
> PROGRAM_NAME " - " PROGRAM_DESCRIPTION "\r\n" ^~~
> 


PROGRAM_DESCRIPTION is not defined


- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXr0YZAAoJEI2t6SdnWbp0AEMP/1spL38xfEeT6qROcL7VAbcv
gIncwgfCUe9zazyA0iDO+xcVTryFEINtz5Jm0yO/MG7+yTixzr+oIpqOP2sxzYfO
axxtz6x+Y65fDhSntsyGD78yQ31zHoiz+qfI1nh24ftXfmkex04jyidGXZeqiQ2p
2LFzymLeruwFFaTMX35mAS08zSZNxNWRBrDaHF0gzacop9c1pOY+NA9/fk130+tg
zJ19uzQUJ9EdXjukYbeM1UzOYtS18C0DAi+nbn78BAjVAReZnVZHO1Cn7R4GIju+
w5xH6ITXAOlZtH21yUl7wEMK0qfCGmyj/gDZd1v+usq77G+2m7gjdObp6k14jd0r
CIRprlt9B720Wcv9HQsAmFeJ/O54hpu/3JDp4o2c06zwmKb9upXmfIbortfKSiD4
Skgw0i+6BKNPT4mX425FmI3oO1bAdZs/lXGe9RqoNU4HvyTqF+BYlb7+WFa05Ssf
CbqE68DOOgOt7uKEbZCFqiwBKNbB2sVS9w6hjMFu0VZI5kgP8DAklbrZ5BDfw2ya
0tepbrE0lZUjhKuGPchyUKSq5Qt2cEhGe5B7mznVdFXUu83gG6BNkyWyWBqbkc3G
NvW2p7DFfcv8URnvsjSUQ4BXvNejPIrHYQad8diBpkRwBpbsuzGC2mm2Pck7flT3
S4M1cZltvkdmqXKglj9w
=YL7d
-END PGP SIGNATURE-
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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 this error:
> 
> 
> In file included from ./src/common/Fork.c:11:0: ./src/common/Fork.c:
> In function ‘cubawait’: ./src/common/stddecl.h:192:29: error:
> ‘cubafun_’ undeclared (first use in this function) #define
> MasterExit() do if( cubafun_.init ) { \ ^ ./src/common/Fork.c:160:3:
> note: in expansion of macro ‘MasterExit’ MasterExit(); ^ 
> ./src/common/stddecl.h:192:29: note: each undeclared identifier is 
> reported only once for each function it appears in #define
> MasterExit() do if( cubafun_.init ) { \ ^ ./src/common/Fork.c:160:3:
> note: in expansion of macro ‘MasterExit’ MasterExit(); ^

The word "fork" should have hinted at the source of the problem. There's
no fork() on Windows, and the whole Fork.c in Cuba is a stub, however it
does call MasterExit(), which is a macro that uses the cubafun_ global
variable, but that variable is only there in non-stub version of Fork.c.

This is a Cuba portability bug. They can reproduce it by tweaking
configure to make it fail to detect fork() (so that HAVE_FORK is undefined)
.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXqwj3AAoJEI2t6SdnWbp0bNcP/0Z9y4De5kas+O0heg53782o
fNRv6ySSrGQeo065WTRoos1MSfT21NEyIIb3anHI6X7GonBhvogMaETMx8TW2W/b
h+H33LzqW1r6sSlpQ7fsB50/xoWpBsAyN44IEB7E2leAYS+gHCjyQ8aaSzjlgWP7
vVPYsnNXEsUmJzO85NXuhSI4Iw0oLUhPkWtb0+qaK7s/iCesFe8ooHxKDDwZrM8C
MEOHUxQajKJ+wf2B86gafMXO7vt/GdKNKEozioHFZyx68tDVh2dmi3m4lRZjmn2T
4cjmwCGjjoTnaCfnjOisRMhTj9BRVoslkHOdH7emqbbv7ZM4c/Mo5jjPLLgF7uy0
1R/DKiHPn0JcL2JK3CSq2oAGOvUZsnkEBB4KPMS1UCaJhrXYwmMf1Pz0mAz50d6E
koUoP3L1cKU13dNHbRboX7UOmz816wdpyAIeAYf8P02CSqittbtw39T3bf2K4YTp
ii092rStkOSh50U2WWxyfybHEG3i0GmiWoyZieM2eoa/ZnA5RF3aIF3TlzhfgiTu
y6FEfdsI62ZinahbC240fJWdh+N5b4N/jGDt6PxwKuXhyG3VQxlExh8OwqWHLV9R
kr1YPDHP+mdkkl9Ywqz3Vxj3uxfAakGEmPfZ6txvq0bQWZ8q7ESFvPBWqndhHQQi
66pE/13KLXYRIL3JqFrd
=VCan
-END PGP SIGNATURE-
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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

> 
> also, you should know that make -j n (parallel make) is not completely
>  viable yet because of the shells it needs to make just to output to 
> stdout when there is a redirection in a makefile which causes massive
>  strange compiler errors.

Can you post the error messages?
And `gcc` and `make` versions?
And maybe a small project (makefile + sources) that demonstrates the proble
m?


- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXqdF4AAoJEI2t6SdnWbp05NUP/j3aOl4NDUMdyI+RcbXfuxF+
Z7ipZD12zNpcOQYfebazE3FCN7QDlI2UKpNHXYrTlY0PO/McWff0NBkBevazHgAo
noHFoTGaMA8hzJIFtQEFH3KGsVWY5ZW0D82uNiHJNeiGX5T341qrNEgccUgV6Tx8
jG48cl2U6FStAwooJ+I0ezgei58wsVn7/DBUtNysAUsk2AYz1BcaWBgbbqyjRrbe
fXS9k4U3BiNrRiXlc0UsPY1+vCxZxkEGRyy69gWhJ60NWFXgQM6TI41BCFhflPUK
osRWzpz1/Zx0PFZtIkgokAfvut03DLLU9cq46/orIzUE3T2KTcjqB7/9AQ5QnBDU
dAQbfN3U/wVMfigCUqoTV1YKrZpa2MnWnd91EQSgcyvP24xr/jJECqN4js+CzP6a
xyD+QbErx5qAbz4R7ZJ09AYCgWCo+ytPqD2Jjvpn2CIT1peFzdwTTGlf/OoHXhUl
CQrhPEulzLagqoGBIGXnQlam6AjUVqXYmE3YcD4Pt9NmOpt+4UMnpCOkBGxlUb46
nON3xeY7q2YqLm7a4Q5dJ3+g8Pl6kCI4djWuluzLlttbTFEQAw6W7aIglXIMAk2i
RCB1rM0s3/Msas6AcAaQOXteGX5wmgiPoYAKI1/+bLkxsIoTxqBSiZt3HvmaD0hC
PudW2QiMkLj0c/fsaCnP
=d2uD
-END PGP SIGNATURE-
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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 support Signals and sigset_t ?
>>> 
>>> No.
>>> 
>>>> Or does MinGQW use SEH and try/except/finally?
>>> 
>>> No.
> 
>> Perfect, thanks.
> 
>> Our problem is runtime feature detection. X86/X64 can result in an 
>> illegal instruction for SSE2 *if* the OS does not support it. We use
>>  SEH on Windows and SigIll handler on Unix/Linux to guard the code 
>> that performs the probe.
> 
>> I realize the OSes that will trap are basically extinct. However,
>> our governance dictates we still support them. Its not too difficult
>> in practice.
> 
>> My next question is, what are the MinGW alternatives to guard the 
>> code if neither SEH nor Signals are available?
> 
> 
> I think, if your licensing situation allows it, that you'd be wise to 
> look at the code of free software programs that successfully detect
> CPU instructions in practice. Usually such code is used by multimedia 
> applications and tools. Oil Runtime Compiler comes to mind.
> 
> Or you can wait until someone more qualified than me replies to this 
> thread. Because my answers above are derived from my own limited 
> experience with these things.
> 
> To expand on my previous answers a bit, MinGW-w64 supports SEH
> exception model for 64-bit, but not for 32-bit (it uses SJLJ or DW2
> there). And, AFAIU, even 64-bit one does not include the support for 
> try/except/finally constructions.
> 
> As for exceptions, there's Vectored Exception Handling, which totally 
> works with MinGW.
> 
> 

Also, as i've been pointed out just now, MSVCRT does have limited signal
handling support, see [1] and [2]. That said, [1] claims that SIGILL is
not generated by the OS. I would suggest you try these out in a small
test program to ensure that they (don't) work the way you expect.

[1] https://msdn.microsoft.com/en-us/library/xdkz3x12.aspx
[2] https://msdn.microsoft.com/en-us/library/dwwzkt4c.aspx

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXn27xAAoJEI2t6SdnWbp0KnkP/RaUVvwYCRaYgmlWvMmwZcHa
imL4FJzNhk+vg6eAd1d+Y1xiQgGtDCSVe9Dqji2/l3G4jzPhvgfPexcnEeMW+4uq
tnyPPN8Cn1QUpkJXg79WxD8Q56siYuZANyqi2rApWtmKOpjWBs+O9WoAehYfaqzj
Olhca38rHJjMtyiyl5zhAn3NtZ8/AO7PA8uUCembDNUdplx+PpNI58weO769KCsE
hwLqIHgCAcbhaDZNA+ktC1/nlog8iWCwub2F28aZ1GZnEvSJR8FzZUXGU/+gHYA5
TNq7SwcDGDUdA8sMrkW7ODH4cgpxFrOR9uYG/MQ8d6bpr1xPXf5gs6IT/CCuR9/1
+i+em897RlS94uL2gAa1vrgmD+6LSy7iIGh5ASK0FxscgEUV8RzU1V50UsPkS81J
gq6UzKXtbuzCC4YI3WbMac+3E7Af22bYgki3NuPGOvmhuR27b2D2pQoVLACL8hnr
7nk50gWyLQEKrM8K8inJitZCvvNJERegBlqQuZ1wlbRS8eUmKSynxxQqZVuJa+5n
i3AUKoexSW9Zgvm+CJrPoBpruWjt4kmOnQAH5ot0UyT/CvrPTrqVJMLNeihf7Sav
H14oZP35a/lWnqew8ZpZxGRVvJTij79FnGXIxtd8HG7E8yMnU/SvgkHdiAuBg5UC
voAVwtBf8v+lsCuqAScx
=C2l+
-END PGP SIGNATURE-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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.
>> 
>>> Or does MinGQW use SEH and try/except/finally?
>> 
>> No.
> 
> Perfect, thanks.
> 
> Our problem is runtime feature detection. X86/X64 can result in an 
> illegal instruction for SSE2 *if* the OS does not support it. We use 
> SEH on Windows and SigIll handler on Unix/Linux to guard the code
> that performs the probe.
> 
> I realize the OSes that will trap are basically extinct. However, our 
> governance dictates we still support them. Its not too difficult in 
> practice.
> 
> My next question is, what are the MinGW alternatives to guard the
> code if neither SEH nor Signals are available?
> 

I think, if your licensing situation allows it, that you'd be wise to
look at the code of free software programs that successfully detect CPU
instructions in practice. Usually such code is used by multimedia
applications and tools. Oil Runtime Compiler comes to mind.

Or you can wait until someone more qualified than me replies to this
thread. Because my answers above are derived from my own limited
experience with these things.

To expand on my previous answers a bit, MinGW-w64 supports SEH exception
model for 64-bit, but not for 32-bit (it uses SJLJ or DW2 there). And,
AFAIU, even 64-bit one does not include the support for
try/except/finally constructions.

As for exceptions, there's Vectored Exception Handling, which totally
works with MinGW.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXnzsGAAoJEI2t6SdnWbp0M1wQAIDbI2jEnGz+DhqmO2RZbwDs
W17Fk8YTBUgUoKsYVsaS821W1f05Jd6KexL+1NHs6RfeehmQZSBSYXRkUAMYxZq5
uBXJhpWevAyvdonq3qZxx4TmiFydCqjCr9aX0mmeyoemjvKJwVRfKiUkYFE2Vq+a
VUan1ikpgih+9n6oDj9uYl8vRidBho7QNc1qpyTNyaQLfvB+/5AQGOZPb1oxm/57
BfAgjT3UZpmzUBRshQGNbT2ub4laLCC/p8BPvk4IMm9JNs1hOgPPoAzIi6AdDaaP
UWVnYi0L5HujLHItWWDEWl+Spseao5Um76ytMu93vsqn+f92/FNcHkkjnxae4mW7
7vLn+xRdByO3pEAHZoe+A/66P6Wl63D917ZOArDZx+qrP89McRuEqjC9SeiF3YB4
SMmZtXW4Vmjfo/thK/o9+8jno8GNzsYyWGooW4yJBF94EFvwyUqvcnOfZ2bZ+vwu
8dsIeTqT0DhNyWoot8CovixMC91utRmYWcU1T93vf2WE1RGOcqbIQiEzO7swVpUZ
cI6sjZNG6fuyvwNokvmpuGZhbwIu1JLA7iWnc/xNqWheBwyaCqGp9E1JeYfLrjez
8B5XrOGp37BjZ5ZcU6+zwNI6y10bs7TLtTNBES1rVhgDxBOAvcGKEuIz2EQk2Pz4
KCtAhFpv9YJiMkXJM8uz
=F109
-END PGP SIGNATURE-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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 SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXnxbOAAoJEI2t6SdnWbp0pfsP/03+Obmqt65s0x5IojWOZWAu
nqMdGRocHUdPStZHhfXmcIdfgVX9eNQufx/3gKISiI86D4Uct85pOKiavs4ioJZD
tuP3Euw1hFR00fTs1aOuXp0ibszZV4hBSps66mv5qglApPrMSUpRIRBwaHMlnqAo
IM2m5uZ5u8XocS5T1rgBBQ3H24+O+QkSddbSjJdPe/ibyMp283qBhScci8F6/Qtp
ndNFC55npKOk/zFXAfTrnaHW5xeEr0RO4OCzLtDf3PkJApXbI1tdFddIaMDMUVI7
0tj/DoZN0Xl6g73PlcXq7kSlaA47WkGSmc+7QHagZLh/qIsYKq5dKquU2NEuttMC
umwWUcEx+K1aKJjz5E/QDpLRwyNLIzYOnJ7iZ4MG3ycEm3BJsOiuy8bSDQPAUiW8
rDMIcu5FuElru9A4SZpzWw1pKeFF09NXQLIzTWyCTNcrTyUA+r6x/kuZdnq/Wj1k
ln8Mo7mBSCx0Fey/nWIelzG8QNUVba7ZtSqKSM0EVPrhLm9aj2DCdSsJozZEdImt
x8CZ75vLN0J0k+/rCpfVTKkLR3AKQo+uXXUVavxZqaO9zCkmhweyugj+IAc2DttQ
OhgOsdhZ+i3bra5RtkCP5vSQnD1x4teUWKnQgIX1J1B/RKrNizxDQuerLRugGYEA
0w1vxCCAWRjDmZuUB8qt
=eZIM
-END PGP SIGNATURE-
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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=]| warning: too many arguments for format
> [-Wformat-extra-args]|
> 
> But there's not a problem in the runtime.
> 
> Would you tell me the reason or some links about that issue?

Look up printf definition that actually gets used stdio.h (do you compile
with -D__USE_MINGW_ANSI_STDIO=1 or some other macros, like _GNU_SOURCE?).

See if it has __attribute__((format(...))). If it does, you have to
follow that format specification (GNU format if 'gnu_printf', MS format
if 'ms_printf' or 'printf').

Note that this has absolutely no effect on what actually happens at
runtime. If you use MinGW ANSI stdio, %lld will work. If you use MSVCRT,
%lld might work, if CRT version is recent enough. If you use gnulib
printf, %lld will work.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXRIifAAoJEOs4Jb6SI2CwCZ4H/2918kXiaoXVLMTNWdn0MnGV
iJMQkZxRKVFkDdo+C+7cZezOyNcpwqPJZFxD+30oRIMm3sZL3B150fn+mob4TZD9
0gMycvTFxvHn0HRm7g0R39BlAGnTgQVPTL4QQHUOC12P9aC5i60IvjXr9W6HFScq
ht6ObpEAfrA3Xi3wAenBIb3/FpaK3AtaYNlotwX286nnQqReG3S7CnBsn1IC9gTR
BQhQDhqlhppFeYVtcDtgbxxpw400Wyubw6HUm0fX9aIJF1GvIV7rFca+iN85g1jC
iG55jBzzapBpvmG9kVSNWcMoL1uru9aByWbeUzsogwwLQvGc0hGm1dqP8igppWU=
=ahhk
-END PGP SIGNATURE-

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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 previously, and they didn't have this problem)?

Did you apply patches? Alexey's patches, for example.


- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXIkNkAAoJEOs4Jb6SI2CwsMoH/jsiPnQioBiHco9W/A34cHBj
hm4gExw+DHBEzp5S0xXur3S0ESYiqxIaC9y5fSeihQITZ8R6apWnMNvFYLekmOrO
3IJ9ahONek4NDC9lpRdLK0EIA7vke2ctkHMel9X59CGDi3Q/hz73dHlT9sMaZjlc
pVlVgCefCfM2osTLbxQeVdIXSRiBz2vx0DuAD2UorX7PILkbK87+e3lF4U+x5Kok
urDhrvlaDl8oGGiiSmyriD6EyN8Zs89Ua+znkxpda0E6MFr7OxHAonpaV/rapys9
sASJltf7QRZ9kna1MRC6KHAE/ItkXAeOc9eg43slLtHITLJn9BaU81+d9Zs7lKc=
=bfuX
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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?
> Show the code or don't get help. I'm quite close to leaving your
> emails in my spam folder, where gmail puts them because Google has
> developed a totally unrelated hatred for Yahoo.
> 

Unrelated: if you have troubles with GMail marking mailing-list posts as
spam, you can go into GMail preferences and set up mail filters (one for
each mailing list) that prevent messages from being submitted to the spam
filter.
Worked for me - now i only get *actual* spam in my Spam IMAP folder.
Before that i had to check it regularly, because Google would mark many
email domains (including Yahoo) as spam sources for failing to comply
with something that i have no understanding of.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXIIs8AAoJEOs4Jb6SI2CwIFoIAJCyz+/Cb4Pkz1Rt0Sa7wB/m
RVoMP6np7l7PBEvVsJIdexciI66vDaeB40m2CkaDW3U3ojZRqF9EtIUZr6I+lCVw
wk+KWAkaB+9mwa2NOFFCiVAuSwL3f+1K0mVADeD9lOin/bYDut/ts27hdEvONFyY
VxQi9LhW0oHjtTUUJHUyCGarL8lMmEEvj1FoFP4KLhvpgWv9pP2PnSGY0ookPEJI
1iszpR4YcctAdoCW78wN+C80G8otfgg1rQ2lBaH7/sQE4jyCo5rko/jB7RZoK+mU
ha/qMde/Pmxjq3fWpTW0krm0zrixk3c3ILcDmdEGQmUYQ3uyx7MrMm5RMu6TIQ4=
=oiCh
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
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 g++ pasting the source code it compiles into the cmd shell?

[LRN]

-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 program it compiles, or does it paste
source code of *any* program?

How are you invoking g++? What does the commandline look?

Does this affect gcc? gfortran? Other compilers from GCC?

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXH+AOAAoJEOs4Jb6SI2Cw2XoH/3NsG8yJGF3LxgEhcwdTI/H5
tf8eVtMQBtZJab/sxygSj7MJhs7+JoZZuJW+6W0URcIbgMaTBvdJHINqhweVUnlB
j2QvSE/uKs5Njhs0fOP78bG/d28iqKQpKUY+yBiamtv02+/tb+rjlid6ECgts4TN
nN0q7zPMQhACVCGsQbdLdJ769b+epyllvQJ/M0f8gns7o2oY2JFQfePPa4HEELuv
3MmdASztXFVr4qurT130/XzVYlh8tdAkp6ZosHm1DqFqFRHwJvuGZwOwgbLrjmmH
CKNRRNfamMoS2x+SxUcgKJMJJjWbWdM4+j+mHCIaJ+FRAvUKoz3lQzn3O8mkyPM=
=NM4q
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
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] Cast certain enums to int

[LRN]

-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.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 bytes.
>>>>> 
>>>>>> Fixes bug #456
>>>>> 
>>>>>> patch is attached
>>>>> 
>>>>> Yeah, and another thing: i don't have x86_64 gcc, nor did i
>>>>> test this with x64 msvc. No idea what sizeof(any enum) on
>>>>> 64-bit architecture is for these two compilers, or how that
>>>>> interacts with sizeof(int) being 8 there.
>>>>> 
>>>> 
>>>> Within both MS ABI and Itanium ABI for x64, sizeof(int) is 4.
>>>> 
>>>> And FWIW, here is the reason of the enumeration problem:
>>>> 
>>>> Quoting from WG14 N1570 (Programming languages — C) [quote] 
>>>> 6.7.2.2 Enumeration specifiers 4 Each enumerated type shall be 
>>>> compatible with char, a signed integer type, or an unsigned 
>>>> integer type. The choice of type is implementation-defined,128)
>>>>  but shall be capable of representing the values of all the 
>>>> members of the enumeration. The enumerated type is incomplete 
>>>> until immediately after the } that terminates the list of 
>>>> enumerator declarations, and complete thereafter. [/quote]
>>>> 
>>>> Here if an enum has both an enumerator less than zero and
>>>> another one greater than 0x7FFF, neither `int` nor
>>>> `unsigned` could be an option because neither is  'capable of
>>>> representing the values of all the members of the enumeration'.
>>>> GCC is doing the correct thing to use a 64-bit integer type.
>>> 
>>> 
>>> Yeah, but the problem here is not being correct. The problem here
>>> is being MSVC-compatible (for obvious reasons).
>>> 
>>> I'm not even sure MSVC is entirely incorrect. If one thinks not of
>>>  numeric values but of byte representations of values, it is 
>>> possible to represent both negative (between 0x8000 and 
>>> 0x) and positive (between 0x and 0x7FFF)
>>> values with a signed 32-bit integer as well as unsigned one -
>>> bytes are the same, only their interpretation changes. If you can
>>> guarantee that 0x, when used in any place where this
>>> enumeration value is expected, is casted to -1 (when actual math
>>> is done; if no math is done, then its value is irrelevant, as long
>>> at it's always the same), then that is just as good as actually
>>> specifying -1 instead of 0x.
>>> 
>>> It seems that the implementation of casting by both GCC and MSVC 
>>> does provide that guarantee. I've made a test program that shoves
>>>  enumeration members into 32-/64-bit signed/unsigned integer 
>>> variables and then prints out their contents. When enumeration 
>>> members are casted to (int) like i proposed, the output for GCC
>>> and MSVC is identical in all cases.
>>> 
>>> I also got around to download x86_64-gcc (first time in the last
>>> few years when i've used a W32 gcc that i have no built myself)
>>> and wrestled a bit with x64 MSVC compiler, managing to compile the
>>> test program for x86_64. Again, the output is identical for both
>>> GCC and MSVC.
>> 
>> I would suggest you cast them to 'unsigned' instead of 'int' for 
>> semantical correctness reasons.
> 
> Casting to (unsigned) does ensure that enum size remains 4, as all 
> values, when cast into (unsigned), do fit into 32-bit unsigned
> integer. However, the output of the test program changes due to this
> cast and looks the same as the initial output of a GCC-compiled test
> program, before i started to cast enum members. So while casting to
> (unsigned) does solve the main problem (enum size), we would have to
> be prepared for unforeseen consequences, if we take that road.
> 
> Curiously, MSVC doesn't give a damn about the casts and never changes
> its behaviour no matter how you cast (or not cast) enumeration members
> in their definition.
> 

Well, since everyone else seems 

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

[LRN]

-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 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
>>>> 
>>>> Yeah, and another thing: i don't have x86_64 gcc, nor did i test
>>>> this with x64 msvc. No idea what sizeof(any enum) on 64-bit
>>>> architecture is for these two compilers, or how that interacts
>>>> with sizeof(int) being 8 there.
>>>> 
>> 
>>> Within both MS ABI and Itanium ABI for x64, sizeof(int) is 4.
>> 
>>> And FWIW, here is the reason of the enumeration problem:
>> 
>>> Quoting from WG14 N1570 (Programming languages — C) [quote] 
>>> 6.7.2.2 Enumeration specifiers 4 Each enumerated type shall be 
>>> compatible with char, a signed integer type, or an unsigned 
>>> integer type. The choice of type is implementation-defined,128) 
>>> but shall be capable of representing the values of all the
>>> members of the enumeration. The enumerated type is incomplete
>>> until immediately after the } that terminates the list of
>>> enumerator declarations, and complete thereafter. [/quote]
>> 
>>> Here if an enum has both an enumerator less than zero and another 
>>> one greater than 0x7FFF, neither `int` nor `unsigned` could
>>> be an option because neither is  'capable of representing the
>>> values of all the members of the enumeration'. GCC is doing the
>>> correct thing to use a 64-bit integer type.
>> 
>> 
>> Yeah, but the problem here is not being correct. The problem here is
>> being MSVC-compatible (for obvious reasons).
>> 
>> I'm not even sure MSVC is entirely incorrect. If one thinks not of 
>> numeric values but of byte representations of values, it is
>> possible to represent both negative (between 0x8000 and
>> 0x) and positive (between 0x and 0x7FFF) values
>> with a signed 32-bit integer as well as unsigned one - bytes are the
>> same, only their interpretation changes. If you can guarantee that
>> 0x, when used in any place where this enumeration value is
>> expected, is casted to -1 (when actual math is done; if no math is
>> done, then its value is irrelevant, as long at it's always the
>> same), then that is just as good as actually specifying -1 instead
>> of 0x.
>> 
>> It seems that the implementation of casting by both GCC and MSVC 
>> does provide that guarantee. I've made a test program that shoves 
>> enumeration members into 32-/64-bit signed/unsigned integer 
>> variables and then prints out their contents. When enumeration 
>> members are casted to (int) like i proposed, the output for GCC and 
>> MSVC is identical in all cases.
>> 
>> I also got around to download x86_64-gcc (first time in the last few
>> years when i've used a W32 gcc that i have no built myself) and 
>> wrestled a bit with x64 MSVC compiler, managing to compile the test 
>> program for x86_64. Again, the output is identical for both GCC and 
>> MSVC.
> 
> I would suggest you cast them to 'unsigned' instead of 'int' for 
> semantical correctness reasons.
> 

Casting to (unsigned) does ensure that enum size remains 4, as all
values, when cast into (unsigned), do fit into 32-bit unsigned integer.
However, the output of the test program changes due to this cast and
looks the same as the initial output of a GCC-compiled test program,
before i started to cast enum members. So while casting to (unsigned)
does solve the main problem (enum size), we would have to be prepared for
unforeseen consequences, if we take that road.

Curiously, MSVC doesn't give a damn about the casts and never changes its
behaviour no matter how you cast (or not cast) enumeration members in
their definition.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXHLRDAAoJEOs4Jb6SI2CwIXMIAIqO/6/2b3xOTs9GG2bVTGY1
UsNyBpioDNI79LoQhso9+xZ3hjF6n5HYUsmulf0pachp8uK2yP8D6xoYs8d1FdUa
CVUgzj86LmGbdpvetWx7+g7ahvLoeDxmapmURwp4Ui+bhl/2Fbd3iUo+o6uSd6/A
oTUgPkzWTE0dVS9wQPPhUsunBVM810rXHrwSznYi9wXk7CTkhuzGwDFDVuIxQWnC

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

[LRN]

-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 > 0x7FFF in the same enum, which,
>>> without this change, prompts GCC to increase enum size to 8
>>> bytes.
>> 
>>> Fixes bug #456
>> 
>>> patch is attached
>> 
>> Yeah, and another thing: i don't have x86_64 gcc, nor did i test
>> this with x64 msvc. No idea what sizeof(any enum) on 64-bit
>> architecture is for these two compilers, or how that interacts with
>> sizeof(int) being 8 there.
>> 
> 
> Within both MS ABI and Itanium ABI for x64, sizeof(int) is 4.
> 
> And FWIW, here is the reason of the enumeration problem:
> 
> Quoting from WG14 N1570 (Programming languages — C) [quote] 6.7.2.2
> Enumeration specifiers 4 Each enumerated type shall be compatible with
> char, a signed integer type, or an unsigned integer type. The choice
> of type is implementation-defined,128) but shall be capable of
> representing the values of all the members of the enumeration. The 
> enumerated type is incomplete until immediately after the } that
> terminates the list of enumerator declarations, and complete
> thereafter. [/quote]
> 
> Here if an enum has both an enumerator less than zero and another one
> greater than 0x7FFF, neither `int` nor `unsigned` could be an
> option because neither is  'capable of representing the values of all
> the members of the enumeration'. GCC is doing the correct thing to use
> a 64-bit integer type.
> 

Yeah, but the problem here is not being correct. The problem here is
being MSVC-compatible (for obvious reasons).

I'm not even sure MSVC is entirely incorrect. If one thinks not of
numeric values but of byte representations of values, it is possible to
represent both negative (between 0x8000 and 0x) and positive
(between 0x and 0x7FFF) values with a signed 32-bit integer
as well as unsigned one - bytes are the same, only their interpretation
changes. If you can guarantee that 0x, when used in any place
where this enumeration value is expected, is casted to -1 (when actual
math is done; if no math is done, then its value is irrelevant, as long
at it's always the same), then that is just as good as actually
specifying -1 instead of 0x.

It seems that the implementation of casting by both GCC and MSVC does
provide that guarantee. I've made a test program that shoves enumeration
members into 32-/64-bit signed/unsigned integer variables and then prints
out their contents. When enumeration members are casted to (int) like i
proposed, the output for GCC and MSVC is identical in all cases.

I also got around to download x86_64-gcc (first time in the last few
years when i've used a W32 gcc that i have no built myself) and wrestled
a bit with x64 MSVC compiler, managing to compile the test program for
x86_64. Again, the output is identical for both GCC and MSVC.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXHKGTAAoJEOs4Jb6SI2CwLxkH/3Ia4+RWoRlhc0e5TAXpxlpc
dbQxP6aNkMDI7URBXQt3vdeu26J76sKx4yjFdamXiTCN9YXJ0Uc8yT/uCu2jMmcb
9EFZMVnEx+CVGVxpHmLHb3Bc/9gjE+ONy7A6a9xqxrzQrb+Awcxy+GUo5dtXnaVV
pbI7WnpfjI9YVlmw1UkkG6YZt3TSSb4wNOGEwxgmoOhHoSTauG/nYhzB5PTPLCg3
KFl8+qr093t39gua9xwLTlz362L5Ga6pCIazBWL3HkwhDE/dvnS0DhJDf6v6sWax
U8HVflCDUL4YPz2qkq/7j1//Mtl7QG4gRyn56OKSN80HsUA9kbVnDo6y/sngaWU=
=JEgw
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
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-public silently drops my posts

[LRN]

-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) was: Re:
>> [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc on March
>> 15.
>> 
>> After some testing (thanks, lh_mouse) i've discovered that the list
>> drops my messages that are signed with PGP/MIME. Messages that are
>> signed with inline PGP, as well as unsigned messages, do come
>> through though.
>> 
>> Please fix. While inline PGP signatures work well enough, they add a
>> lot of cruft that would be better left out.
>> 
>> Anyway, i'll re-sent a few messages with inline signatures and keep 
>> sending with inline signatures, until one of the list admins does
>> something .
> 
> Why do you need to pgp sign your message at all?

Because i can't encrypt them (if i do, most people won't be able to
decrypt them, as they lack my public key; which is not unexpected, since
this is a public mailing list).

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXG4OjAAoJEOs4Jb6SI2CwYG4H/3tESyqXEXMZ2wCO1+asXQSC
pPGajgcy/QCMn8WDfG9h0ERjBcLDsWQrX25tx2DHnCeF8hoUtMHI0Qh/cOgXXKe1
AMXSjpMFlSnG5XoMHTDcywxiF7xWeE+Heu5KZcfte8XTBAkqA9msQ9MrdNWvu53s
Z50laLst2woRPOSzw9x7tSz7zw24GGAlgquhSatB+YP7OJhXOHwl2P77oNVyM77z
87kIs9wKgBr9YrnVm/iNiycqlegQ1oJWiGeoMdkaWIl2lceediVsS55olgeno/Gz
E3KJlbGMlix0XIEaCvrD/tyTtB+cH2vtbugblVKh2Pmn5HF/rPcrB1KdKrlt7nU=
=XS32
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
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] Cast certain enums to int

[LRN]

-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 bytes.
> 
> Fixes bug #456
> 
> patch is attached
> 
> 

Yeah, and another thing: i don't have x86_64 gcc, nor did i test this
with x64 msvc. No idea what sizeof(any enum) on 64-bit architecture is
for these two compilers, or how that interacts with sizeof(int) being 8
there.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXGn3RAAoJEOs4Jb6SI2CwS2AIAIuG7nleJ9X4pERg9sxlWu6q
dEWhYl+aOTRdoFnimozkwbPF6MkdJYpES68UzFeB23/pDgIz42NlTskvEOAPQRh8
EXN7TIX8mjGMY7Z/K+s4Dq/36R+6PX8Dv4r9EonlWI/gzo0/IJR2OMMaCJINC+sU
6y/NBr2ah9v+bVVQbFFUFz3MGxMrztX49BllLj+UGzQg/1Uzf1OnTs0gCk+OOUQm
Oq5u3pe1BNEVke2K9Ximya6feHZeX1S78spg/IK4VYic+7rYdOmcJplNBZ+E1N3W
3KONK3LCmEcsgeeYM2kwBVpJ5s7rTAyv+1dAIauDRx79Y+sEz4XxA1UmIShDpik=
=dZF5
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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.asciiribbon.org


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXGmoeAAoJEOs4Jb6SI2CwniAH/3J6K6mIeg9umMmXCsVaQBYI
g284CunAflOetmymEffMKdmmeVWYiuFVvp5hIXjeDftZhVFBdb5r2oI2AeYu4vum
zPseCvxTwfVxKncTHcZuss8Vi+mSHVR5AlfTNK8kn2F4ffgPG9PpC34No4nmKDzl
0iiiuI6ZEuhT3fk6jvvgFa3erUm75j73pGSLDOGdacjSamY5oqOqAwrsSrnT0HDX
yeqwz8aZX1JLiYqxTCirbZs6WSdkhYTgBhUKaakU/LR1jHu9UJ8a2MLo67DeZM2K
kbF77EA+tC7tIOCLp1/BSm5DAFy2Ya7UmVz9d8VkwpTCsTF0C8jkiorRVAWribI=
=Pmxh
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

-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< ascii ribbon - stop html email! - www.asciiribbon.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXGl48AAoJEOs4Jb6SI2Cwp3QH/1bl0MLE0oK9bDBo8Gsi+IXN
0Ra2B8AbXWgE2HvZepac8EkymxfqvuyIPSqZKgAqxgw+KsR9MiVzrVMAspInL9cw
sgyBbCa4UE7BoEjqWVPdYxRzMebRs7uQFvKgDX0RW4TMsZgexSDsgEIU2rRyzW8f
cmv31uPwWEedSCTvfrHi94ic8Ken3EkuIUXE11ShRAFL4JgY7L1wdkIzqwU6BgKX
jmLiW6TWtPxDHXoZ4l8Qf9s+OCOSf3wOP0C+xCQC56cKCGRJ060M7wxM3nGg2QtL
aP4jpsgy3zgI/mxNf6N+BPySRc510N+W9lW6IeBPUBtk2ESJa6h043z9BKMS97Q=
=Pk8Z
-END PGP SIGNATURE-
From 9c267d96aac4bd3cc00aaf4a174312fc55f0a32c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Fri, 22 Apr 2016 05:12:09 +
Subject: [PATCH] Cast certain enums to int

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
---
 mingw-w64-headers/include/adoint_backcompat.h | 10 +++---
 mingw-w64-headers/include/tom.h   | 50 +--
 mingw-w64-headers/include/wingdi.h| 34 +-
 3 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/mingw-w64-headers/include/adoint_backcompat.h 
b/mingw-w64-headers/include/adoint_backcompat.h
index bbc3c42..f816cb6 100755
--- a/mingw-w64-headers/include/adoint_backcompat.h
+++ b/mingw-w64-headers/include/adoint_backcompat.h
@@ -461,11 +461,11 @@ extern "C" {
   } ConnectModeEnum;
   typedef DECLSPEC_UUID ("0570--0010-8000-00AA006D2EA4")
   enum RecordCreateOptionsEnum { adCreateCollection = 0x2000,
-adCreateStructDoc = 0x8000,
-adCreateNonCollection = 0,
-adOpenIfExists = 0x200,
-adCreateOverwrite = 0x400,
-adFailIfNotExists = -1
+adCreateStructDoc = (int) 0x8000,
+adCreateNonCollection = (int) 0,
+adOpenIfExists = (int) 0x200,
+adCreateOverwrite = (int) 0x400,
+adFailIfNotExists = (int) -1
   } RecordCreateOptionsEnum;
   typedef DECLSPEC_UUID ("0571--0010-8000-00AA006D2EA4")
   enum RecordOpenOptionsEnum { adOpenRecordUnspecified = -1,
diff --git a/mingw-w64-headers/include/tom.h b/mingw-w64-headers/include/tom.h
index c3bc7a3..1bb7545 100644
--- a/mingw-w64-headers/include/tom.h
+++ b/mingw-w64-headers/include/tom.h
@@ -121,31 +121,31 @@ extern "C" {
 #ifndef __tom_LIBRARY_DEFINED__
 #define __tom_LIBRARY_DEFINED__
   typedef enum __MIDL___MIDL_itf_tom__0001 {
-tomFalse = 0,tomTrue = -1,tomUndefined = -999,tomToggle = 
-998,tomAutoColor = -997,tomDefault = -996,tomSuspend = -995,
-tomResume = -994,tomApplyNow = 0,tomApplyLater = 1,tomTrackParms = 
2,tomCacheParms = 3,tomBackward = 0xc001,tomForward = 0x3fff,
-tomMove = 0,tomExtend = 1,tomNoSelection = 0,tomSelectionIP = 
1,tomSelectionNormal = 2,tomSelectionFrame = 3,tomSelectionColumn = 4,
-tomSelectionRow = 5,tomSelectionBlock = 6,tomSelectionInlineShape = 
7,tomSelectionShape = 8,tomSelStartActive = 1,tomSelAtEOL = 2,
-tomSelOvertype = 4,tomSelActive = 8,tomSelReplace = 16,tomEnd = 0,tomStart 
= 32,tomCollapseEnd = 0,tomCollapseStart = 1,tomClientCoord = 256,
-tomNone = 0,tomSingle = 1,tomWords = 2,tomDouble = 3,tomDotted = 4,tomDash 
= 5,tomDashDot = 6,tomDashDotDot = 7,tomWave = 8,tomThick = 9,
-tomHair = 10,tomLineSpaceSingle = 0,tomLineSpace1pt5 = 
1,tomLineSpaceDouble = 2,tomLineSpaceAtLeast = 3,tomLineSpaceExactly = 4,
-tomLineSpaceMultiple = 5,tomAlignLeft = 0,tomAlignCenter = 1,tomAlignRight 
= 2,tomAlignJustify = 3,tomAlignDecimal = 3,tomAlignBar = 4,
-tomAlignInterWord = 3,tomAlignInterLetter = 4,tomAlignScaled = 
5,tomAlignGlyphs = 6,tomAlignSnapGrid = 7,tomSpaces = 0,tomDots = 1,tomDashes = 
2,
-tomLines = 3,tomThickLines = 4,tomEquals = 5,tomTabBack = -3,tomTabNext = 
-2,tomTabHere = -1,tomListNone = 0,tomListBullet = 1,
-tomListNumberAsArabic = 2,tomListNumberAsLCLetter = 
3,tomListNumberAsUCLetter = 4,tomListNumberAsLCRoman = 5,tomListNumberAsUCRoman 
= 6,
-tomListNumberAsSequence = 7,tomListParentheses = 0x1,tomListPeriod = 
0x2,tomListPlain = 0x3,tomCharacter = 1,tomWord = 2,
-tomSentence = 3,tomParagraph = 4,tomLine = 5,tomStory = 6,tomScreen = 
7,tomSection = 8,tomColumn = 9,tomRow = 10,tomWindow = 11,tomCell = 12,
-tomCharFormat = 13,tomParaFormat = 14,tomTable = 15,tomObject = 
16,tomMatchWord = 2,tomMatchCase = 4,tomMatchPattern = 8,tomUnknownStory = 0,
-tomMainTextStory = 1,tomFootnotesStory = 2,tomEndnotesStory = 
3,tomCommentsStory = 

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

[LRN]

-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 ribbon - stop html email! - www.asciiribbon.org

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXGl4FAAoJEOs4Jb6SI2Cws4YH/26ATu+vL6TLHmfD43cgeUcX
lfQkAx7gCRYJfGh7rgSlGXKkQfEamCXadH4/OAizTzVLJNf7XYASpPzCtSNunUw4
C+GOWCsD6Rho5nduuoW6nd+JB8ZCky8cVYGKbKfQZZnzAJwIoi1uIzqaSWoWqk0Y
9wbW8uigjolsdVWc+sBMqQuPHXbdLTxWA2mUIA64I+/cUN5m/Dwui6qfLiYSW4zr
iA3U7eUk/xvUSOdEPKfanPF0uiq+rVzprgiQDlkk2BZUGtX7Zin3ps78M7dKrZL9
UYmuqoirjmLZsf/SstTM3IQqSm51OcTq8yl2H548LwOAV2fDpCdbFTh90PLuYxM=
=x1tk
-END PGP SIGNATURE-
From 05c30154fe5762c4303414e6387a0a301208b9c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= 
Date: Fri, 22 Apr 2016 05:29:22 +
Subject: [PATCH] Check for ms_printf format and non-NULL format in MS printf
 funcs.

mingw-w64 ANSI printf has these checks, so why not MS printf?
---
 mingw-w64-headers/crt/stdio.h | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 3b49ddd..9f1cfff 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-headers/crt/stdio.h
@@ -374,41 +374,53 @@ int vsnprintf (char *__stream, size_t __n, const char 
*__format, __builtin_va_li
 /*
  * Default configuration: simply direct all calls to MSVCRT...
  */
+  __attribute__((__format__ (ms_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl fprintf(FILE * __restrict__ _File,const char * __restrict__ 
_Format,...);
+  __attribute__((__format__ (ms_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
   int __cdecl printf(const char * __restrict__ _Format,...);
+  __attribute__((__format__ (ms_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl sprintf(char * __restrict__ _Dest,const char * __restrict__ 
_Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 
+  __attribute__((__format__ (ms_printf, 2, 0))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl vfprintf(FILE * __restrict__ _File,const char * __restrict__ 
_Format,va_list _ArgList);
+  __attribute__((__format__ (ms_printf, 1, 0))) __MINGW_ATTRIB_NONNULL(1)
   int __cdecl vprintf(const char * __restrict__ _Format,va_list _ArgList);
+  __attribute__((__format__ (ms_printf, 2, 0))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl vsprintf(char * __restrict__ _Dest,const char * __restrict__ 
_Format,va_list _Args) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 
+  __attribute__((__format__ (ms_scanf, 2, 3))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl fscanf(FILE * __restrict__ _File,const char * __restrict__ 
_Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+  __attribute__((__format__ (ms_scanf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
   int __cdecl scanf(const char * __restrict__ _Format,...) 
__MINGW_ATTRIB_DEPRECATED_SEC_WARN;
+  __attribute__((__format__ (ms_scanf, 2, 3))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl sscanf(const char * __restrict__ _Src,const char * __restrict__ 
_Format,...) __MINGW_ATTRIB_DEPRECATED_SEC_WARN;
 #ifdef _GNU_SOURCE
   int __cdecl vasprintf(char ** __restrict__ ret,const char * __restrict__ 
format,va_list ap)  __attribute__ ((format (__MINGW_PRINTF_FORMAT, 2, 0)));;
   int __cdecl asprintf(char ** __restrict__ ret,const char * __restrict__ 
format,...) __attribute__ ((format (__MINGW_PRINTF_FORMAT, 2, 3)));
 #endif /*_GNU_SOURCE*/
 #ifndef __NO_ISOCEXT  /* externs in libmingwex.a */
+  __attribute__((__format__ (ms_scanf, 1, 0))) __MINGW_ATTRIB_NONNULL(1)
   int __cdecl __ms_vscanf(const char * __restrict__ Format, va_list argp);
+  __attribute__((__format__ (ms_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl __ms_vfscanf (FILE * __restrict__ fp, const char * __restrict__ 
Format,va_list argp);
+  __attribute__((__format__ (ms_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2)
   int __cdecl __ms_vsscanf (const char * __restrict__ _Str,const char * 
__restrict__ Format,va_list argp);
 
   __mingw_ovr
-  __MINGW_ATTRIB_NONNULL(2)
+  __attribute__((__format__ (ms_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2)
   int vfscanf (FILE *__stream,  const char *__format, __builtin_va_list 
__local_argv)
   {
 return __ms_vfscanf (__stream, __format, __local_argv);
   }
 
   __mingw_ovr
-  __MINGW_ATTRIB_NONNULL(2)
+  __attribute__((__format__ (ms_scanf, 2, 0))) __MINGW_ATTRIB_NONNULL(2)
   int vsscanf (const char * __restrict__ __source, const char * __restrict__ 
__format, __builtin_va_list __local_argv)
   {
 return __ms_vsscanf( __source, __format, __local_argv );
   }
   __mingw_ovr
-  __MINGW_ATTRIB_NONNULL(1)
+  __attribute__((__format__ (ms_scanf, 1, 0))) __MINGW_ATTRIB_NONNULL(1)
   int vscanf(const char *__format,  __builtin_va_list __local_argv)
   

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

[LRN]

-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 discovered that the list drops
my messages that are signed with PGP/MIME. Messages that are signed with
inline PGP, as well as unsigned messages, do come through though.

Please fix. While inline PGP signatures work well enough, they add a lot
of cruft that would be better left out.

Anyway, i'll re-sent a few messages with inline signatures and keep
sending with inline signatures, until one of the list admins does something
.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXGl21AAoJEOs4Jb6SI2CwJsUH/2GOo1aCvERaEHgV852zIIUI
RUE3FTopXspu6cJUK1Bnk/Aj1ZtDB4ZqRWXrTa4DfK5KTVlIJ0E9XVH4NvCslTcW
pWOQfTmc9LPiaNvtYhQ+FAY0N2f9vBWzJ6kg81O61ZHnXNi0pTkh+LG8CtUcDIxl
Dt4P5UOfpEp498Fp74Xzyd2jvk0cwzQNFTyL6XC+ZfHwJmGaFgpD6p8FlJBBpErW
H6+WvQhahKRWOQ0If5321RUv/Nbzoog/76wM78SG3j2hzXDF/vRcFkyon9kXTpII
xDGC2up6LVjVweZnP7E2fdcKVcqoyWRLU9chOrnMAOHdL22zW+RzcSBD9o2/XB4=
=ijc4
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] yet another test mail

[LRN]

-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+LSg02C9pQhxsHsF1BM
x7oyHMgTZEIKCDKa7y94TyEI5yvC4ptwTZcv7xhs0vxoKZO2FD4ZLxOy+C8UVhtg
t2UT8jIONjTYypYf14zyTV4lwWM+JgAtsHZaQ2nQVtCy+VDZwkcQM9E1Ww8RsDsP
mwIYJiX3Q+dm+DLzzE28TGDqVZGcbPippjS0iu7Z+WPQHSYb6KFeFdyApBCQIYiH
HgT6gqhnOUB+q1vvwF9ngOeZF2eOczo6E3spHF6wMaefhCHnzoYYml9YAktPvE39
TvtCR176MFCm+yPblfubVOIs5Y4IhIjqRUJyNH7kctZBLozlwJiPADBw4hK9e9o=
=Lwv1
-END PGP SIGNATURE-

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] another test mail

[LRN]

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 Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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?

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] profiling

[LRN]

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 but may be 
> there is something more specific to mingw64?
> 

AFAIU, gprof can't profile shared libraries. At all.


-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 not nice, but acceptable.


-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
___
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 will support Vulkan?

[LRN]

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 to have
appropriate Vulkan headers (also, you will need a Vulkan extension library
to correctly fill out Vulkan vtables).

That is, assuming that Vulkan behaves identically to OpenGL as far as API
design goes.

Correct me if i'm wrong.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 DLL injection with
>> CreateRemoteThread, and API hooking by patching the IAT.
>>
>> So Examine is working well, now, but I have 2 questions, about
>> _strdup() and malloc() :
>>
>> 1) If I call malloc() in a program, it is detected by Examine. If I
>> call _strdup(), malloc is not detected at all, while MSDN says that
>> _strdup() "calls malloc to allocate storage space" (see
>> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
>> have an idea why malloc() is  not catched ?
> 
> You could have more luck by hot
> patching malloc function itself, but I don't think it's the right solution.

AFAIK, gcc sanitizer does exactly that. Except that it was not ported to
W32/gcc (it works only on POSIX/gcc or W32/MSVC).

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 patching the IAT.
> 
> So Examine is working well, now, but I have 2 questions, about
> _strdup() and malloc() :
> 
> 1) If I call malloc() in a program, it is detected by Examine. If I
> call _strdup(), malloc is not detected at all, while MSDN says that
> _strdup() "calls malloc to allocate storage space" (see
> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
> have an idea why malloc() is  not catched ?
> 
> 2) So to fix 1), i've just patched the IAT to detect _strdup() (but
> i'm not satisfied with this). Now if I call strdup(), _strdup() is not
> detected. I thought first that strdup() was a macro, but it is
> actually declared in string.h. Does someone know why strdup() is not
> catched too ?

One possibility is the strdup builtin that gcc has. Though i'm not sure
what exactly does it do, aside from checking for argument not being a NULL
pointer.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org



signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 i can't remember right now, claim that MS libraries were
UCS-2 initially, then later quietly converted to UTF-16 under the hood.


-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 arbitrary number. Is the file opened in binary mode? Anything
 significant around the 262th byte in the file contents?

 No, that's a zlib compressed binary.

 Starting from offset 0x100 (256):
 f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88

 Byte 262 is 0x1a (26)

Sorry, i've got nothing.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 other GCC toolchains was that they tended 
 to have enough usable relative search paths that you could still move 
 them around wherever you want, as long as you didn't put *anything* at 
 the hardcoded locations (/mingw or the like). That said, I haven't tried 
 this with a MinGW-w64-based toolchain other than my own in a while.
 

This is correct. Windows versions of gcc are fully relocatable (and were
for years), the only problem you'll encounter with unpatched (or
poorly-configured) gcc build is that anything in current
drive\mingw\(include|lib) (or whatever the hardcoded path ends up pointing
at) will be used by gcc (which is usually not what you want).

Back when i still used mingw.org, they had /mingw path hardcoded and would
therefore suck up anything in currentdrive\mingw\(include|lib). This
is/was a widely-known bug.

Many builds (especially of Mingw-w64) hardcode (again, hardcoding is not
intentional, it's a side effect of the build process that no one bothers to
try to eliminate) an absolute DOS path to a directory that is unlikely to
exist, thus sidestepping the issue this way.

My solution, which eliminates the problem completely (AFAICS) was outlined
earlier. Other builds may have something similar going as well.

What you see as an archaic engineering feat that should be fixed as a bug
is actually a quirk of a very complex non-Windows-oriented buildsystem of a
piece of software that is very strict on what changes are accepted
(especially to the buildsystem), who are they accepted from (you need to do
a copyright assignment to contribute to gcc) and how they are vetted.
This is just not worth bothering with for anyone who knows what the problem
is. Fixing it on a per-build basis is easy enough.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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
 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 other GCC toolchains was that they tended
 to have enough usable relative search paths that you could still move
 them around wherever you want, as long as you didn't put *anything* at
 the hardcoded locations (/mingw or the like). That said, I haven't tried
 this with a MinGW-w64-based toolchain other than my own in a while.


 This is correct. Windows versions of gcc are fully relocatable (and were
 for years), the only problem you'll encounter with unpatched (or
 poorly-configured) gcc build is that anything in current
 drive\mingw\(include|lib) (or whatever the hardcoded path ends up pointing
 at) will be used by gcc (which is usually not what you want).
 
 It is not correct in my testing. If I don't have a c:\mingw but try to 
 compile/link uisng a mingw-64/mingw32 installation directly I get an 
 error message saying that a dll ( libwinpthread-1.dll ) can not be found 
 even though it is in the same directory as the compiler and linker. With 
 a c:\mingw directory I do not get this error.

That's a new one.

Please provide your directory layout for your toolchain, location of the
libwinpthread-1.dll as well as the contents of PATH environment variable at
the moment when you run compiler/linker.

 Why in the world should I have to put anything in my PATH if these 
 releases are self-enclosed ? I am executing gcc from the exact same 
 directory where the libwinpthread-1.dll exists. All the initial exes and 
 dlls are in this directory. The Windows search order for DLLs tells me 
 that the DLL should be found automatically if it is in the same 
 directory as whatever module loads it. The whole point of a 
 self-enclosed distribution is that one should not have to do any tricks, 
 such as setting a PATH variable, for the distribution to just work.
 
 If I have multiple mingw-64 distributions having to add the bin 
 directory of each one to the PATH before I use that distribution is just 
 as bad as having to have a c:\mingw directory link pointing to the one I 
 execute.
 
 The correct design of mingw-64 ( or mingw ) would have me only execute 
 the correct gcc and/or ld in the directory of the distribution to 
 compile/link a program, without having to do anything further.

I think it should be noted that back when i still used MSVC, Microsoft
*did* modify PATH when running Visual Studio, and they have a developer
command prompt, which is just a batch file that sets up environment
variables and starts the command prompt.

As for why this might not work in case of gcc, i can't tell you exactly,
but gcc does consist of multiple executables, and not all of them reside in
the bin subdirectory. Try adding bin subdirectory to PATH, see if anything
improves.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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
 instead of searching for include files and libraries relative to its
 installation structure ?

 This is a side-effect of the way gcc is built. It's possible to mitigate
 this by
 1) Cross-compiling gcc (instead of compiling it on Windows) from Cygwin or
 a GNU system
 2) Patching gcc to throw away include and lib paths that start with '/'
 when running on Windows.

 If not cross-compiled, gcc will have an absolute DOS path in its search
 list (this is mitigated by building it in a randomly-named staging
 directory deep in the temp tree to ensure that this has near-zero
 probability of acting up in real life); some people settle for that.
 
 Thanks for the info. I guess the question then is why gcc is built in 
 such backwards ( to this programmer ) way. Hardcoding absolute paths, in 
 programing circa the year 2015, seems abolutely lunacy. But I don't 
 expect an answer to why gcc works the way it does on this mailing list.

gcc has a POSIX-centric (and complex) buildsystem. Hardcoding sysroot paths
is not considered a deadly sin there.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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. The
 biggest issue being that you cannot simply build Python extensions with
 MinGW(-w64). For that issue, and the flicker of activity, see this bug
 report:
 http://bugs.python.org/issue4709
 
 Now, it seems that VS2015 is coming with a new Universal CRT, which will
 be what the new Python version supports. Paule Moore, a new Python
 contributor, is prepared to help significantly as I understand it, but he
 deems support for the new CRT somewhat of a requirement to get streamlined
 support for the GCC/Windows/Python combination. What are the chances of
 this being added to MinGW-w64 soon? 

IANAL, but UCRT might also improve the licensing situation, where GPLv2
programs can't legally link to anything other than msvcrt.dll that comes
with the OS; if UCRT is, legally, an OS component (and from the way MS
describes it, that seems to be the case), GPLv3 (and, hopefully, GPLv2)
programs will be able to use it. That could serve as an extra motivation
for UCRT support in MinGW-w64.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 definitive right now, as i don't have
access to my gcc-building machine.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

On 05.05.2015 16:50, JonY wrote:
 On 5/5/2015 03:47, Alon Bar-Lev wrote:
 this somewhat reduces the error checking, but makes code and usage nicer.
 
 Hi,
 
 Thanks for the patch, but I'm rather ambivalent about keeping the
 top-level configure.
 
 It doesn'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 they can be improved -
fine. If they can't - no big deal.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 the cross compiler it self 
 is in good shape, since I can cross compile SDL1 without any issues.
 
 This is what SDL2 gives me:
 
CC build/SDL_render_d3d11.lo
 /home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:140:19:
  
 error: static declaration of 'IID_IDXGIFactory2' follows non-static 
 declaration
   static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, { 
 0x87, 0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } };
 ^
 In file included from 
 /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/combaseapi.h:156:0,
   from 
 /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/objbase.h:14,
   from 
 /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/ole2.h:17,
   from 
 /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11_1.h:12,
   from 
 /home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:34:
 /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/dxgi1_2.h:759:1: 
 note: previous declaration of 'IID_IDXGIFactory2' was here
   DEFINE_GUID(IID_IDXGIFactory2, 0x50c83a1c, 0xe072, 0x4c48, 0x87,0xb0, 
 0x36,0x30,0xfa,0x36,0xa6,0xd0);
   ^

At a glance it looks like SDL_render_d3d11.c declares and defines
IID_IDXGIFactory2, and mingw's dxgi1_2.h declares IID_IDXGIFactory2 as well
(and defines it in some library, likely libuuid.a).

Apparently, SDL2 was written against a SDK (likely mingw.org) that has no
IID_IDXGIFactory2.

The fix is to remove
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, { 0x87,
0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } };
from SDL2 (or at least ifdef it out based on some macro from dxgi1_2.h).

At a glance, anyway.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[LRN]

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 files for implibs 
 seem
 to be special somehow).

 https://msdn.microsoft.com/en-us/library/windows/desktop/ms649033%28v=vs.85%29.aspx

 Figured it out, here's a patch

 your patch is fine beside some nits.  Why are you removing
 function-entries like GetGUIThreadInfo@8, SetSystemTimer@16,
 ChangeDisplaySettingsW@8, EditWndProc@16, etc?  Please take care not
 to remove exports of older variants.
 
 Otherwise patch is ok with re-adding those removed symbols.

Here are amended patches. As we agreed on #mingw-w64, old functions are kept
around, functions that have prototypes in our headers get appropriate argument
length, functions that don't have prototypes in our headers get the newest
argument length from gendef.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org
From e2eeb85588342957eabb92755772edda5ccbc8af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= lrn1...@gmail.com
Date: Sat, 25 Apr 2015 09:15:16 +
Subject: [PATCH 1/4] Add functions (mostly undocumented ones) to user32 (XP)

The additions were extracted from a .def file produced by gendef on XP SP3.
Some functions were moved around to preserve alphabetic order.
Trailing spaces were removed.
---
 mingw-w64-crt/lib32/user32.def | 95 --
 1 file changed, 92 insertions(+), 3 deletions(-)
 mode change 100644 = 100755 mingw-w64-crt/lib32/user32.def

diff --git a/mingw-w64-crt/lib32/user32.def b/mingw-w64-crt/lib32/user32.def
old mode 100644
new mode 100755
index cc84505..f28deb5
--- a/mingw-w64-crt/lib32/user32.def
+++ b/mingw-w64-crt/lib32/user32.def
@@ -3,6 +3,8 @@ EXPORTS
 ActivateKeyboardLayout@8
 AdjustWindowRect@12
 AdjustWindowRectEx@16
+AlignRects@16
+AllowForegroundActivation@0
 AllowSetForegroundWindow@4
 AnimateWindow@12
 AnyPopup@0
@@ -19,7 +21,9 @@ BroadcastSystemMessageA@20
 BroadcastSystemMessageExA@24
 BroadcastSystemMessageExW@24
 BroadcastSystemMessageW@20
+BuildReasonArray@12
 CalcChildScroll@8
+CalcMenuBar@20
 CallMsgFilter@8
 CallMsgFilterA@8
 CallMsgFilterW@8
@@ -30,9 +34,9 @@ CascadeChildWindows@8
 CascadeWindows@20
 ChangeClipboardChain@8
 ChangeDisplaySettingsA@8
-ChangeDisplaySettingsW@8
 ChangeDisplaySettingsExA@20
 ChangeDisplaySettingsExW@20
+ChangeDisplaySettingsW@8
 ChangeMenuA@20
 ChangeMenuW@20
 CharLowerA@4
@@ -59,6 +63,8 @@ CheckMenuRadioItem@20
 CheckRadioButton@16
 ChildWindowFromPoint@12
 ChildWindowFromPointEx@16
+CliImmSetHotKey@16
+ClientThreadSetup@0
 ClientToScreen@8
 ClipCursor@4
 CloseClipboard@0
@@ -80,6 +86,7 @@ CreateCursor@28
 CreateDesktopA@24
 CreateDesktopW@24
 CreateDialogIndirectParamA@20
+CreateDialogIndirectParamAorW@24
 CreateDialogIndirectParamW@20
 CreateDialogParamA@20
 CreateDialogParamW@20
@@ -91,10 +98,13 @@ CreateMDIWindowA@40
 CreateMDIWindowW@40
 CreateMenu@0
 CreatePopupMenu@0
+CreateSystemThreads@8
 CreateWindowExA@48
 CreateWindowExW@48
 CreateWindowStationA@16
 CreateWindowStationW@16
+CsrBroadcastSystemMessageExW@24
+CtxInitUser32@0
 DdeAbandonTransaction@12
 DdeAccessData@8
 DdeAddData@16
@@ -145,13 +155,18 @@ DestroyCaret@0
 DestroyCursor@4
 DestroyIcon@4
 DestroyMenu@4
+DestroyReasons@4
 DestroyWindow@4
+DeviceEventWorker@20
 DialogBoxIndirectParamA@20
+DialogBoxIndirectParamAorW@24
 DialogBoxIndirectParamW@20
 DialogBoxParamA@20
 DialogBoxParamW@20
+DisableProcessWindowsGhosting@0
 DispatchMessageA@4
 DispatchMessageW@4
+DisplayExitWindowsWarnings@4
 DlgDirListA@20
 DlgDirListComboBoxA@20
 DlgDirListComboBoxW@20
@@ -164,6 +179,8 @@ DragDetect@12
 DragObject@20
 DrawAnimatedRects@16
 DrawCaption@16
+DrawCaptionTempA@28
+DrawCaptionTempW@28
 DrawEdge@16
 DrawFocusRect@8
 DrawFrame@16
@@ -171,6 +188,7 @@ DrawFrameControl@16
 DrawIcon@16
 DrawIconEx@36
 DrawMenuBar@4
+DrawMenuBarTemp@20
 DrawStateA@40
 DrawStateW@40
 DrawTextA@20
@@ -187,6 +205,7 @@ EndDialog@8
 EndMenu@0
 EndPaint@8
 EndTask@12
+EnterReaderModeHelper@4
 EnumChildWindows@12
 EnumClipboardFormats@4
 EnumDesktopWindows@12
@@ -221,9 +240,11 @@ FrameRect@12
 FreeDDElParam@8
 GetActiveWindow@0
 GetAltTabInfo@20
-GetAltTabInfoA@20  
-GetAltTabInfoW@20  
+GetAltTabInfoA@20
+GetAltTabInfoW@20
 GetAncestor@8
+GetAppCompatFlags2@4
+GetAppCompatFlags@4
 GetAsyncKeyState@4
 GetCapture@0
 GetCaretBlinkTime@0
@@ -247,6 +268,7 @@ GetClipboardSequenceNumber@0
 GetClipboardViewer@0
 GetComboBoxInfo@8
 GetCursor@0
+GetCursorFrameInfo@20
 GetCursorInfo@4
 GetCursorPos@4
 GetDC@4
@@ -269,6 +291,7 @@ GetGuiResources@8
 GetIconInfo@8
 GetInputDesktop@0
 GetInputState@0
+GetInternalWindowPos@12
 GetKBCodePage@0
 GetKeyNameTextA@12
 GetKeyNameTextW@12
@@ -312,13 +335,16 @@ GetParent@4
 GetPriorityClipboardFormat@8
 GetProcessDefaultLayout@4

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

[LRN]

On 25.04.2015 10:04, Kai Tietz wrote:
 2015-04-25 6:41 GMT+02:00 LRN wrote:
 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 files for implibs 
 seem
 to be special somehow).

 https://msdn.microsoft.com/en-us/library/windows/desktop/ms649033%28v=vs.85%29.aspx

 Figured it out, here's a patch

 your patch is fine beside some nits.  Why are you removing
 function-entries like GetGUIThreadInfo@8, 
Not removing, just moving it up 4 lines (gendef sorts symbols alphabetically,
apparently)
 SetSystemTimer@16,
gendef says this function is absent in my version of user32.dll
 ChangeDisplaySettingsW@8,
Not removing, just moving
 EditWndProc@16
A bug in gendef, i'll commit later with EditWndProc restored to its rightful
place, and with @16 instead of @20.

Also note that between Windows 2003 (the oldest version i can readily access)
and Windows 7 some interesting changes (according to gendef) happened to
user32.dll. I've attached the diff. Some highlights:

-CreateSystemThreads@16
+CreateSystemThreads ; Check!!! Couldn't determine function argument count.
Function doesn't return.

(in my patch i've made it CreateSystemThreads@28, but i was either wrong, or
the function acquired extra arguments).

-DeviceEventWorker@20
+DeviceEventWorker@24
-GetAppCompatFlags@4
+GetAppCompatFlags@8

Acquired an extra argument?

-InitializeWin32EntryTable@4
-SetConsoleReserveKeys@8
-IsProcess16Bit@0
-KillSystemTimer@8
-SetLogonNotifyWindow@4
-SetSystemTimer@16
-Win32PoolAllocationStats@24

Functions disappeared.

-UpdatePerUserSystemParameters@8
+UpdatePerUserSystemParameters@4

Lost an argument? Or a gendef bug?

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org

--- defs_2003\\user32.dll.def	2015-04-25 08:47:24.890625000 +0300
+++ defs_7\\user32.dll.def	2015-04-25 09:00:21.129158700 +0300
@@ -5,7 +5,10 @@
 ;
 LIBRARY USER32.dll
 EXPORTS
+ord_1500@16 @1500
+ord_1501@4 @1501
 ActivateKeyboardLayout@8
+AddClipboardFormatListener@4
 AdjustWindowRect@12
 AdjustWindowRectEx@16
 AlignRects@16
@@ -28,12 +31,14 @@
 BroadcastSystemMessageW@20
 BuildReasonArray@12
 CalcMenuBar@20
+CalculatePopupWindowPosition@20
 CallMsgFilter@8
 CallMsgFilterA@8
 CallMsgFilterW@8
 CallNextHookEx@16
 CallWindowProcA@20
 CallWindowProcW@20
+CancelShutdown@0
 CascadeChildWindows@8
 CascadeWindows@20
 ChangeClipboardChain@8
@@ -43,11 +48,20 @@
 ChangeDisplaySettingsW@8
 ChangeMenuA@20
 ChangeMenuW@20
+ChangeWindowMessageFilter@8
+ChangeWindowMessageFilterEx@16
 CharLowerA@4
 CharLowerBuffA@8
 CharLowerBuffW@8
 CharLowerW@4
 CharNextA@4
+ord_1550@12 @1550
+ord_1551@8 @1551
+ord_1552@8 @1552
+ord_1553@12 @1553
+ord_1554@8 @1554
+ord_1555@16 @1555
+ord_1556@4 @1556
 CharNextExA@12
 CharNextW@4
 CharPrevA@8
@@ -61,10 +75,12 @@
 CharUpperBuffA@8
 CharUpperBuffW@8
 CharUpperW@4
+CheckDesktopByThreadId@4
 CheckDlgButton@12
 CheckMenuItem@12
 CheckMenuRadioItem@20
 CheckRadioButton@16
+CheckWindowThreadDesktop@8
 ChildWindowFromPoint@12
 ChildWindowFromPointEx@16
 CliImmSetHotKey@16
@@ -73,8 +89,12 @@
 ClipCursor@4
 CloseClipboard@0
 CloseDesktop@4
+CloseGestureInfoHandle@4
+CloseTouchInputHandle@4
 CloseWindow@4
 CloseWindowStation@4
+ConsoleControl@12
+ControlMagnification@8
 CopyAcceleratorTableA@12
 CopyAcceleratorTableW@12
 CopyIcon@4
@@ -86,6 +106,8 @@
 CreateCaret@16
 CreateCursor@28
 CreateDesktopA@24
+CreateDesktopExA@32
+CreateDesktopExW@32
 CreateDesktopW@24
 CreateDialogIndirectParamA@20
 CreateDialogIndirectParamAorW@24
@@ -100,7 +122,7 @@
 CreateMDIWindowW@40
 CreateMenu@0
 CreatePopupMenu@0
-CreateSystemThreads@16
+CreateSystemThreads ; Check!!! Couldn't determine function argument count. Function doesn't return. 
 CreateWindowExA@48
 CreateWindowExW@48
 CreateWindowStationA@16
@@ -140,15 +162,15 @@
 DdeSetUserHandle@12
 DdeUnaccessData@4
 DdeUninitialize@4
-DefDlgProcA@16
-DefDlgProcW@16
+DefDlgProcA = NTDLL.NtdllDialogWndProc_A ; Check!!! forwards to NTDLL.NtdllDialogWndProc_A
+DefDlgProcW = NTDLL.NtdllDialogWndProc_W ; Check!!! forwards to NTDLL.NtdllDialogWndProc_W
 DefFrameProcA@20
 DefFrameProcW@20
 DefMDIChildProcA@16
 DefMDIChildProcW@16
 DefRawInputProc@12
-DefWindowProcA@16
-DefWindowProcW@16
+DefWindowProcA = NTDLL.NtdllDefWindowProc_A ; Check!!! forwards to NTDLL.NtdllDefWindowProc_A
+DefWindowProcW = NTDLL.NtdllDefWindowProc_W ; Check!!! forwards to NTDLL.NtdllDefWindowProc_W
 DeferWindowPos@32
 DeleteMenu@12
 DeregisterShellHookWindow@4
@@ -159,7 +181,7 @@
 DestroyMenu@4
 DestroyReasons@4
 DestroyWindow@4
-DeviceEventWorker@20
+DeviceEventWorker@24
 DialogBoxIndirectParamA@20
 DialogBoxIndirectParamAorW@24
 DialogBoxIndirectParamW@20
@@ -168,6 +190,8 @@
 DisableProcessWindowsGhosting@0
 DispatchMessageA@4
 DispatchMessageW@4
+DisplayConfigGetDeviceInfo@4
+DisplayConfigSetDeviceInfo@4
 DisplayExitWindowsWarnings@4
 DlgDirListA@20
 DlgDirListComboBoxA@20
@@ -177,6 +201,8 @@
 DlgDirSelectComboBoxExW@16

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

[LRN]

On 25.04.2015 11:23, LRN wrote:
 On 25.04.2015 10:04, Kai Tietz wrote:
 2015-04-25 6:41 GMT+02:00 LRN wrote:
 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 files for implibs 
 seem
 to be special somehow).

 https://msdn.microsoft.com/en-us/library/windows/desktop/ms649033%28v=vs.85%29.aspx

 Figured it out, here's a patch

 your patch is fine beside some nits.  Why are you removing
 function-entries like GetGUIThreadInfo@8, 
 Not removing, just moving it up 4 lines (gendef sorts symbols alphabetically,
 apparently)
 SetSystemTimer@16,
 gendef says this function is absent in my version of user32.dll
 ChangeDisplaySettingsW@8,
 Not removing, just moving
 EditWndProc@16
 A bug in gendef, i'll commit later with EditWndProc restored to its rightful
 place, and with @16 instead of @20.
 
 Also note that between Windows 2003 (the oldest version i can readily access)
 and Windows 7 some interesting changes (according to gendef) happened to
 user32.dll. I've attached the diff. Some highlights:
 
 -CreateSystemThreads@16
 +CreateSystemThreads ; Check!!! Couldn't determine function argument count.
 Function doesn't return.
 
 (in my patch i've made it CreateSystemThreads@28, but i was either wrong, or
 the function acquired extra arguments).
 
 -DeviceEventWorker@20
 +DeviceEventWorker@24
 -GetAppCompatFlags@4
 +GetAppCompatFlags@8
 
 Acquired an extra argument?
 
 -InitializeWin32EntryTable@4
 -SetConsoleReserveKeys@8
 -IsProcess16Bit@0
 -KillSystemTimer@8
 -SetLogonNotifyWindow@4
 -SetSystemTimer@16
 -Win32PoolAllocationStats@24
 
 Functions disappeared.
 
 -UpdatePerUserSystemParameters@8
 +UpdatePerUserSystemParameters@4
 
 Lost an argument? Or a gendef bug?
 

Found an old XP SP3 VM, here are the changes between XP SP3 and 2003 (2003 SP2,
actually, that's the machine i mentioned earlier). Highlights:

-CreateSystemThreads@8
+CreateSystemThreads@16

Definitely something changing here between versions!

+IsProcess16Bit@0

So this is a 2003-only function?

-PrivateSetDbgTag@8
-PrivateSetRipFlags@8
-QueryUserCounters@20

QueryUserCounters is mentioned here[1]

-RegisterUserApiHook@8
+RegisterUserApiHook@4

Puzzling.

-VRipOutput@0
-VTagOutput@0

So these mysterious functions didn't make it into Server 2003, but 7 has them?
Weird.

What do we do with all these functions? Keep all? What about functions that
change their arguments? Not to mention that we probably have no prototypes for
them (any of them; though i didn't check) in our headers.

[1] http://www.oocities.org/the_real_sz/misc/bear_.htm

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org
--- defs_xpsp3\\user32.dll.def	2015-04-25 11:36:29.50174 +0300
+++ defs_2003\\user32.dll.def	2015-04-25 08:47:24.890625000 +0300
@@ -100,7 +100,7 @@
 CreateMDIWindowW@40
 CreateMenu@0
 CreatePopupMenu@0
-CreateSystemThreads@8
+CreateSystemThreads@16
 CreateWindowExA@48
 CreateWindowExW@48
 CreateWindowStationA@16
@@ -291,7 +291,7 @@
 GetInputDesktop@0
 GetInputState@0
 GetInternalWindowPos@12
-GetKBCodePage ; Check!!! forwards to GetOEMCP in KERNEL32.dll (ordinal 395)
+GetKBCodePage ; Check!!! forwards to GetOEMCP in KERNEL32.dll (ordinal 403)
 GetKeyNameTextA@12
 GetKeyNameTextW@12
 GetKeyState@4
@@ -429,7 +429,9 @@
 IsHungAppWindow@4
 IsIconic@4
 IsMenu@4
+IsProcess16Bit@0
 IsRectEmpty@4
+IsSETEnabled@0
 IsServerSideWindow@4
 IsWinEventHookInstalled@4
 IsWindow@4
@@ -437,6 +439,7 @@
 IsWindowInDestroy@4
 IsWindowUnicode@4
 IsWindowVisible@4
+IsWow64Message@0
 IsZoomed@4
 KillSystemTimer@8
 KillTimer@8
@@ -526,11 +529,8 @@
 PrivateExtractIconExW@20
 PrivateExtractIconsA@32
 PrivateExtractIconsW@32
-PrivateSetDbgTag@8
-PrivateSetRipFlags@8
 PtInRect@12
 QuerySendMessage@4
-QueryUserCounters@20
 RealChildWindowFromPoint@12
 RealGetWindowClass@12
 RealGetWindowClassA@12
@@ -555,7 +555,7 @@
 RegisterShellHookWindow@4
 RegisterSystemThread@8
 RegisterTasklist@4
-RegisterUserApiHook@8
+RegisterUserApiHook@4
 RegisterWindowMessageA@4
 RegisterWindowMessageW@4
 ReleaseCapture@0
@@ -703,6 +703,7 @@
 UnregisterMessagePumpHook@0
 UnregisterUserApiHook@0
 UpdateLayeredWindow@36
+UpdateLayeredWindowIndirect@8
 UpdatePerUserSystemParameters@8
 UpdateWindow@4
 User32InitializeImmEntryTable@4
@@ -712,8 +713,6 @@
 UserLpkTabbedTextOut@48
 UserRealizePalette@4
 UserRegisterWowHandlers@8
-VRipOutput@0
-VTagOutput@0
 ValidateRect@8
 ValidateRgn@8
 VkKeyScanA@4


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk

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

[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 files for implibs seem
 to be special somehow).
 
 https://msdn.microsoft.com/en-us/library/windows/desktop/ms649033%28v=vs.85%29.aspx
 
Figured it out, here's a patch

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org
From a9e29d514fa0c4aead942774c4f4bf3796e8a121 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= lrn1...@gmail.com
Date: Sat, 25 Apr 2015 04:41:07 +
Subject: [PATCH] Update lib32/user32.def (gendef'ed from Windows 7 SP1
 version)

---
 mingw-w64-crt/lib32/user32.def | 208 +++--
 1 file changed, 199 insertions(+), 9 deletions(-)

diff --git a/mingw-w64-crt/lib32/user32.def b/mingw-w64-crt/lib32/user32.def
index cc84505..298b06d 100644
--- a/mingw-w64-crt/lib32/user32.def
+++ b/mingw-w64-crt/lib32/user32.def
@@ -1,8 +1,13 @@
 LIBRARY USER32.dll
 EXPORTS
+ord_1500@16 @1500
+ord_1501@4 @1501
 ActivateKeyboardLayout@8
+AddClipboardFormatListener@4
 AdjustWindowRect@12
 AdjustWindowRectEx@16
+AlignRects@16
+AllowForegroundActivation@0
 AllowSetForegroundWindow@4
 AnimateWindow@12
 AnyPopup@0
@@ -19,27 +24,39 @@ BroadcastSystemMessageA@20
 BroadcastSystemMessageExA@24
 BroadcastSystemMessageExW@24
 BroadcastSystemMessageW@20
-CalcChildScroll@8
+BuildReasonArray@12
+CalcMenuBar@20
+CalculatePopupWindowPosition@20
 CallMsgFilter@8
 CallMsgFilterA@8
 CallMsgFilterW@8
 CallNextHookEx@16
 CallWindowProcA@20
 CallWindowProcW@20
+CancelShutdown@0
 CascadeChildWindows@8
 CascadeWindows@20
 ChangeClipboardChain@8
 ChangeDisplaySettingsA@8
-ChangeDisplaySettingsW@8
 ChangeDisplaySettingsExA@20
 ChangeDisplaySettingsExW@20
+ChangeDisplaySettingsW@8
 ChangeMenuA@20
 ChangeMenuW@20
+ChangeWindowMessageFilter@8
+ChangeWindowMessageFilterEx@16
 CharLowerA@4
 CharLowerBuffA@8
 CharLowerBuffW@8
 CharLowerW@4
 CharNextA@4
+ord_1550@12 @1550
+ord_1551@8 @1551
+ord_1552@8 @1552
+ord_1553@12 @1553
+ord_1554@8 @1554
+ord_1555@16 @1555
+ord_1556@4 @1556
 CharNextExA@12
 CharNextW@4
 CharPrevA@8
@@ -53,12 +70,16 @@ CharUpperA@4
 CharUpperBuffA@8
 CharUpperBuffW@8
 CharUpperW@4
+CheckDesktopByThreadId@4
 CheckDlgButton@12
 CheckMenuItem@12
 CheckMenuRadioItem@20
 CheckRadioButton@16
+CheckWindowThreadDesktop@8
 ChildWindowFromPoint@12
 ChildWindowFromPointEx@16
+CliImmSetHotKey@16
+ClientThreadSetup@0
 ClientToScreen@8
 ClipCursor@4
 CloseClipboard@0
@@ -67,6 +88,8 @@ CloseGestureInfoHandle@4
 CloseTouchInputHandle@4
 CloseWindow@4
 CloseWindowStation@4
+ConsoleControl@12
+ControlMagnification@8
 CopyAcceleratorTableA@12
 CopyAcceleratorTableW@12
 CopyIcon@4
@@ -78,8 +101,11 @@ CreateAcceleratorTableW@8
 CreateCaret@16
 CreateCursor@28
 CreateDesktopA@24
+CreateDesktopExA@32
+CreateDesktopExW@32
 CreateDesktopW@24
 CreateDialogIndirectParamA@20
+CreateDialogIndirectParamAorW@24
 CreateDialogIndirectParamW@20
 CreateDialogParamA@20
 CreateDialogParamW@20
@@ -91,10 +117,13 @@ CreateMDIWindowA@40
 CreateMDIWindowW@40
 CreateMenu@0
 CreatePopupMenu@0
+CreateSystemThreads@28 ; Check!!! Couldn't determine function argument count. 
Function doesn't return. 
 CreateWindowExA@48
 CreateWindowExW@48
 CreateWindowStationA@16
 CreateWindowStationW@16
+CsrBroadcastSystemMessageExW@24
+CtxInitUser32@0
 DdeAbandonTransaction@12
 DdeAccessData@8
 DdeAddData@16
@@ -145,13 +174,20 @@ DestroyCaret@0
 DestroyCursor@4
 DestroyIcon@4
 DestroyMenu@4
+DestroyReasons@4
 DestroyWindow@4
+DeviceEventWorker@24
 DialogBoxIndirectParamA@20
+DialogBoxIndirectParamAorW@24
 DialogBoxIndirectParamW@20
 DialogBoxParamA@20
 DialogBoxParamW@20
+DisableProcessWindowsGhosting@0
 DispatchMessageA@4
 DispatchMessageW@4
+DisplayConfigGetDeviceInfo@4
+DisplayConfigSetDeviceInfo@4
+DisplayExitWindowsWarnings@4
 DlgDirListA@20
 DlgDirListComboBoxA@20
 DlgDirListComboBoxW@20
@@ -160,10 +196,14 @@ DlgDirSelectComboBoxExA@16
 DlgDirSelectComboBoxExW@16
 DlgDirSelectExA@16
 DlgDirSelectExW@16
+DoSoundConnect@0
+DoSoundDisconnect@0
 DragDetect@12
 DragObject@20
 DrawAnimatedRects@16
 DrawCaption@16
+DrawCaptionTempA@28
+DrawCaptionTempW@28
 DrawEdge@16
 DrawFocusRect@8
 DrawFrame@16
@@ -171,13 +211,17 @@ DrawFrameControl@16
 DrawIcon@16
 DrawIconEx@36
 DrawMenuBar@4
+DrawMenuBarTemp@20
 DrawStateA@40
 DrawStateW@40
 DrawTextA@20
 DrawTextExA@24
 DrawTextExW@24
 DrawTextW@20
-EditWndProc@16
+DwmGetDxSharedSurface@24
+DwmStartRedirection@4
+DwmStopRedirection@0
+EditWndProc@20
 EmptyClipboard@0
 EnableMenuItem@12
 EnableScrollBar@12
@@ -187,6 +231,7 @@ EndDialog@8
 EndMenu@0
 EndPaint@8
 EndTask@12
+EnterReaderModeHelper@4
 EnumChildWindows@12
 EnumClipboardFormats@4
 EnumDesktopWindows@12
@@ -219,11 +264,14 @@ FlashWindow@8
 FlashWindowEx@4
 FrameRect@12
 FreeDDElParam@8
+FrostCrashedWindow@8
 GetActiveWindow@0
 GetAltTabInfo@20
-GetAltTabInfoA@20

Re: [Mingw-w64-public] std::thread and memory leaks

[LRN]

On 22.04.2015 14:37, Yaron Keren wrote:
 2015-04-22 14:15 GMT+03:00 LRN:
 On 22.04.2015 14:02, Óscar Fuentes wrote:
 LRN writes:

 Here's a patch to fix this.
 It does solve the problem for the simple testcase, but i have no idea
 how it
 would behave in the wild, i didn't test it on anything else. One might
 notice
 that it is set to crash when certain things happen. I'm not sure
 whether these
 things would happen with correct real-life code. If they do, we'll have
 to find
 another way.

 +  if (EPERM == pthread_spin_destroy (old))
 +{
 +  fprintf(stderr, Error cleaning up spin_keys for thread %lu\n,
 GetCurrentThreadId ());
 +  abort ();
 +}

 Why is fprintf used for reporting critical errors? On a GUI application
 running outside of a debugger that's a guarantee that the message will
 be invisible.

 Probably true, but that's the easiest debug-message-spewing method i could
 think of at the time. Also, it calls abort() immediately after that, which
 terminates the application. Once debugger is hooked up, the message should
 be
 (hopefully) seen (unless the app eliminates stderr completely).

 Point is that this isn't supposed to happen at all, and right now eveyone's
 goal should be to figure out whether it actually happens or not. If it
 does,
 then this code won't go live anyway. If it doesn't, this debug message
 won't be
 relevant.

 stderr is not likely to show up anywhere with a GUI program.
 The standard practice in Windows is to use OutputDebugString.

 https://msdn.microsoft.com/en-us/library/windows/desktop
 /aa363362%28v=vs.85%29.aspx

Here. Happy now?

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org
From 98864d12cb2d695b31e504f8c748f6fe57aff8f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= lrn1...@gmail.com
Date: Wed, 22 Apr 2015 06:34:36 +
Subject: [PATCH] Try to eliminate spin_keys memleak

---
 mingw-w64-libraries/winpthreads/src/thread.c | 53 ++--
 1 file changed, 43 insertions(+), 10 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/thread.c 
b/mingw-w64-libraries/winpthreads/src/thread.c
index 5c40f12..1f7968f 100644
--- a/mingw-w64-libraries/winpthreads/src/thread.c
+++ b/mingw-w64-libraries/winpthreads/src/thread.c
@@ -23,6 +23,7 @@
 #include windows.h
 #include strsafe.h
 #include stdio.h
+#include stdlib.h
 #include malloc.h
 #include signal.h
 #include pthread.h
@@ -374,6 +375,38 @@ free_pthread_mem (void)
   pthread_mutex_unlock (mtx_pthr_locked);
 }
 
+static void
+replace_spin_keys (pthread_spinlock_t *old, pthread_spinlock_t new)
+{
+  if (old == NULL)
+return;
+
+  if (EPERM == pthread_spin_destroy (old))
+{
+#define THREADERR Error cleaning up spin_keys for thread 
+#define THREADERR_LEN ((sizeof (THREADERR) / sizeof (*THREADERR)) - 1)
+#define THREADID_LEN THREADERR_LEN + 66 + 1 + 1
+  int i;
+  char thread_id[THREADID_LEN] = THREADERR;
+  _ultoa ((unsigned long) GetCurrentThreadId (), 
thread_id[THREADERR_LEN], 10);
+  for (i = THREADERR_LEN; thread_id[i] != '\0'  i  THREADID_LEN - 1; 
i++)
+{
+}
+  if (i  THREADID_LEN - 1)
+{
+  thread_id[i] = '\n';
+  thread_id[i + 1] = '\0';
+}
+#undef THREADERR
+#undef THREADERR_LEN
+#undef THREADID_LEN
+  OutputDebugStringA (thread_id);
+  abort ();
+}
+
+  *old = new;
+}
+
 /* Hook for TLS-based deregistration/registration of thread.  */
 static BOOL WINAPI
 __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
@@ -415,7 +448,7 @@ __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
  t-h = NULL;
}
  pthread_mutex_destroy (t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
  push_pthread_mem (t);
  t = NULL;
  TlsSetValue (_pthread_tls, t);
@@ -434,14 +467,14 @@ __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
CloseHandle (t-h);
  t-h = NULL;
  pthread_mutex_destroy(t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
  push_pthread_mem (t);
  t = NULL;
  TlsSetValue (_pthread_tls, t);
  return TRUE;
}
  pthread_mutex_destroy(t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
}
   else if (t)
{
@@ -449,7 +482,7 @@ __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
CloseHandle (t-evStart);
  t-evStart = NULL;
  pthread_mutex_destroy (t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
}
 }
   return TRUE;
@@ -963,7 +996,7

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

[LRN]

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 files for implibs seem
to be special somehow).

https://msdn.microsoft.com/en-us/library/windows/desktop/ms649033%28v=vs.85%29.aspx

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] std::thread and memory leaks

[LRN]

On 02.10.2014 10:03, niXman wrote:
 JonY 2014-10-02 02:11:
 On 9/28/2014 14:44, lh_mouse wrote:
 mingw-w64-libraries/winpthread/src/spinlock.c:66
   int initrv = pthread_spin_init (lock, 
 PTHREAD_PROCESS_PRIVATE);

 There is no corresponding pthread_spin_destroy() for this lock, hence 
 its memory leaks.


 Kai, ping.
 
 I do not see where there should be the appropriate 
 pthread_spin_destroy().
 
 Moreover, I wrote the test that shows that no leaks when using 
 spinlocks:
 for ( int i = 0; i  1024*1024; ++i ) {
pthread_spinlock_t s;
pthread_spin_init(s, PTHREAD_PROCESS_PRIVATE);
pthread_spin_lock(s);
pthread_spin_unlock(s);
pthread_spin_destroy(s);
 }
 
 

Here's a patch to fix this.
It does solve the problem for the simple testcase, but i have no idea how it
would behave in the wild, i didn't test it on anything else. One might notice
that it is set to crash when certain things happen. I'm not sure whether these
things would happen with correct real-life code. If they do, we'll have to find
another way.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org
From 6a5533c313371a2c4d552fc42510aa29a81cc035 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
 =?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= lrn1...@gmail.com
Date: Wed, 22 Apr 2015 06:34:36 +
Subject: [PATCH] Try to eliminate spin_keys memleak

---
 mingw-w64-libraries/winpthreads/src/thread.c | 35 
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/mingw-w64-libraries/winpthreads/src/thread.c 
b/mingw-w64-libraries/winpthreads/src/thread.c
index 5c40f12..4872601 100644
--- a/mingw-w64-libraries/winpthreads/src/thread.c
+++ b/mingw-w64-libraries/winpthreads/src/thread.c
@@ -374,6 +374,21 @@ free_pthread_mem (void)
   pthread_mutex_unlock (mtx_pthr_locked);
 }
 
+static void
+replace_spin_keys (pthread_spinlock_t *old, pthread_spinlock_t new)
+{
+  if (old == NULL)
+return;
+
+  if (EPERM == pthread_spin_destroy (old))
+{
+  fprintf(stderr, Error cleaning up spin_keys for thread %lu\n, 
GetCurrentThreadId ());
+  abort ();
+}
+
+  *old = new;
+}
+
 /* Hook for TLS-based deregistration/registration of thread.  */
 static BOOL WINAPI
 __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
@@ -415,7 +430,7 @@ __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
  t-h = NULL;
}
  pthread_mutex_destroy (t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
  push_pthread_mem (t);
  t = NULL;
  TlsSetValue (_pthread_tls, t);
@@ -434,14 +449,14 @@ __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
CloseHandle (t-h);
  t-h = NULL;
  pthread_mutex_destroy(t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
  push_pthread_mem (t);
  t = NULL;
  TlsSetValue (_pthread_tls, t);
  return TRUE;
}
  pthread_mutex_destroy(t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
}
   else if (t)
{
@@ -449,7 +464,7 @@ __dyn_tls_pthread (HANDLE hDllHandle, DWORD dwReason, 
LPVOID lpreserved)
CloseHandle (t-evStart);
  t-evStart = NULL;
  pthread_mutex_destroy (t-p_clock);
- t-spin_keys = new_spin_keys;
+ replace_spin_keys (t-spin_keys, new_spin_keys);
}
 }
   return TRUE;
@@ -963,7 +978,7 @@ __pthread_self_lite (void)
   t-tid = GetCurrentThreadId();
   t-evStart = CreateEvent (NULL, 1, 0, NULL);
   t-p_clock = PTHREAD_MUTEX_INITIALIZER;
-  t-spin_keys = new_spin_keys;
+  replace_spin_keys (t-spin_keys, new_spin_keys);
   t-sched_pol = SCHED_OTHER;
   t-h = NULL; //GetCurrentThread();
   if (!DuplicateHandle(GetCurrentProcess(), GetCurrentThread(), 
GetCurrentProcess(), t-h, 0, FALSE, DUPLICATE_SAME_ACCESS))
@@ -1521,7 +1536,7 @@ pthread_create (pthread_t *th, const pthread_attr_t 
*attr, void *(* func)(void *
   while (++redo = 4);
 
   tv-p_clock = PTHREAD_MUTEX_INITIALIZER;
-  tv-spin_keys = new_spin_keys;
+  replace_spin_keys (tv-spin_keys, new_spin_keys);
   tv-valid = LIFE_THREAD;
   tv-sched.sched_priority = THREAD_PRIORITY_NORMAL;
   tv-sched_pol = SCHED_OTHER;
@@ -1559,7 +1574,7 @@ pthread_create (pthread_t *th, const pthread_attr_t 
*attr, void *(* func)(void *
   if (tv-evStart)
CloseHandle (tv-evStart);
   pthread_mutex_destroy (tv-p_clock);
-  tv-spin_keys = new_spin_keys;
+  replace_spin_keys (tv-spin_keys, new_spin_keys);
   tv-evStart = NULL;
   tv-h = 0;
   if (th)
@@ -1621,7 +1636,7 @@ pthread_join (pthread_t t, void **res)
   if (res)
 *res = tv-ret_arg;
   pthread_mutex_destroy (tv-p_clock);

[Mingw-w64-public] msvcrt import library interface

[LRN]

Should libmsvcrt.a provide the most recent interface (matching the newest
available msvcr**.dll) or the least recent interface (matching the oldest
msvcr**.dll still supported by mingw-w64)?

Because right now it's somewhere in between.
For example, it does not expose _except_handler4_common

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] A logo for MinGW-w64

[LRN]

On 15.04.2015 17:38, Kai Tietz wrote:
 2015-04-15 16:06 GMT+02:00 Earnie :
 Caution, MINGW is a registered trademark.  Its use must get permission from
 the owners of the trademark.

 
 Thanks for the point that MINGW got a trademark (see
 https://trademarks.justia.com/860/17/mingw-86017856.html ). I was
 filled 2013-07-23,  It is clear that from your side nothing
 constructive will show up.  As mingw-w64 exits much longer before this
 date, I don't see how this trademark actually affects us.  Especially
 in context of choosing an logo.   We don't plan to use MINGW
 Organization's logo (see trademark The Mark Drawing is: 4000 -
 Standard character mark Typeset., ).
 
 Nevertheless I am not a lawyer, and therefore I will contact our
 lawyers to get here clarification how this impacts us and if we need
 to deal with this assault.
 

It says that the owner (IIUC) is SPI INC - http://www.spi-inc.org/
Surely, they don't sound too bad? I hope things will work out.

-- 
O ascii ribbon - stop html email! - www.asciiribbon.org


0x922360B0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public