Been 3 months since my last email, what's going on with this?
On Tue, Oct 19, 2021 at 11:03 PM Jonathan Marler
wrote:
> Jacek were you able to forward this discussion to Wine? If so do you have
> a link to that discussion? Thanks.
>
> On Sun, Sep 5, 2021 at 9:27 AM LIU Hao w
It's been 3 months since the last email on this thread but the patch hasn't
been integrated, what's the status?
On Tue, Oct 19, 2021 at 11:01 PM Jonathan Marler
wrote:
> > Just wondering. Is libdsparse.a actually required in a project? I
>
> None that I know of,
Jacek were you able to forward this discussion to Wine? If so do you have
a link to that discussion? Thanks.
On Sun, Sep 5, 2021 at 9:27 AM LIU Hao wrote:
> 在 2021-09-05 23:00, Jacek Caban 写道:
> >
> > They come from widl, so if we want this change, then widl needs to be
> changed instead. It l
> Just wondering. Is libdsparse.a actually required in a project? I
None that I know of, except for my win32metadata projection that ensures I
can link to all the libraries on Windows with all the functions/libraries
that are declared in the win32metadata.
On Mon, Oct 11, 2021 at 11:33 PM Biswa
I've included the patch in the body of this email, but I'm using a
webclient which can trample the whitespace so I've also included the patch
as an attachment.
>From db50bba6b5fa5492292da7c152d001f8d62b7246 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Mon, 11 Oct 2
I could but this project builds with MSVC and I noticed that the MSVC
headers are using the same include style for these 2 particular files.
Note that we only need to change these 2 lines, to fix this. What reason
is there not to change these 2 lines to fix this issue? If you google it
there appe
That's odd, I attached it in the first email sent Aug 25. Here's the patch
inline with my email and attached again
>From 2ba8f0e43213f09f85cf653a8f0a726d9873399d Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Wed, 25 Aug 2021 10:35:19 -0600
Subject: [PATCH] wtypes.h: rep
Been another 4 days, anyone able to bring this patch in or review?
On Mon, Aug 30, 2021 at 3:36 PM Jonathan Marler
wrote:
> Ping. The issue that this fixes is easy to reproduce. Just try to
> compile any project with the mingw headers and add a file named "rpc.h" to
>
revious message
should fix it.
On Wed, Aug 25, 2021 at 10:42 AM Jonathan Marler
wrote:
> This replaces the include style for rpc.h and rpcndr.h inside the wtypes.h
> header. I found this issue when trying to compile my WindowsNfs project
> found here: https://github.com/marler8997/W
This replaces the include style for rpc.h and rpcndr.h inside the wtypes.h
header. I found this issue when trying to compile my WindowsNfs project
found here: https://github.com/marler8997/WindowsNfs. This project
contains a file named "Rpc.h". This broke the mingw header files because
wtypes.h e
Ah that's good to know so we can look out for that when we take the next
release. We try our best and we appreciate the time and help.
On Fri, Jul 23, 2021, 12:08 AM Martin Storsjö wrote:
> On Thu, 22 Jul 2021, Jonathan Marler wrote:
>
> > The linker errors were found by a Zi
48 PM Martin Storsjö wrote:
> Hi,
>
> On Thu, 22 Jul 2021, Jonathan Marler wrote:
>
> > Yes I think the problem was with my environment. I had libws2_32.lib
> > available but did not have libws2_32.a, so I was missing the symbols
> coming
> > from the source f
Wed, 21 Jul 2021, Jonathan Marler wrote:
>
> > Yeah definitely revert, those redefinition errors are bad news.
> > The problem though is that I still get these undefined symbol errors
> > even with -lws2_32 with Clang. Forgive me if I'm mistaken here, but in
> > orde
that right? If so, I don't see them in there which is why I think I'm
getting the linker errors.
On Wed, Jul 21, 2021 at 4:17 PM Martin Storsjö wrote:
> Hi,
>
> On Wed, 21 Jul 2021, LIU Hao wrote:
>
> > 在 7/20/21 11:44 AM, Jonathan Marler 写道:
> >> How's
How's this?
On Sun, Jul 18, 2021 at 12:18 AM LIU Hao wrote:
> 在 2021-07-13 17:44, Jonathan Marler 写道:
> >> Do things work out if you use the existing __mingw_ovr attribute define?
> >
> > It appears to fix the issue yes. Here's a patch with that solution:
&
Yes I double checked and it appears I'm able to take the address of these
functions even when they are static. This means last patch I sent that
uses __mingw_ovr should work fine.
On Tue, Jul 13, 2021 at 11:52 PM Martin Storsjö wrote:
> On Tue, 13 Jul 2021, Jonathan Marler wrote:
>
I think the ideal solution would allow programs to take the address of
these functions since MSVC allows it.
For this we could either find a version of inline attributes that allows
emission and doesn't cause duplicate symbol errors during link, or, keep
the headers as they are and provide the the
patch with that solution:
From 8f4c87ad8b19bf904ae0357a09e52477d49abea3 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Tue, 13 Jul 2021 03:37:56 -0600
Subject: [PATCH] Use __mingw_ovr for WS2TCPIP_INLINE
---
mingw-w64-headers/include/ws2ipdef.h | 4 ++--
mingw-w64-headers/include
That is a good point. Thanks for your help/guidance with this. Here's a
new patch where I've copied __CRT_INLINE and created a new __MSVC_INLINE
which is meant to behave like the origin MSVC inline
From fb39d994898b00ae52106b72f6c835821ae2b455 Mon Sep 17 00:00:00 2001
From: Jonat
>From 2a06367f7c63d5782ae51af162d68ed2e783e389 Mon Sep 17 00:00:00 2001
From: Jonathan Marler
Date: Tue, 13 Jul 2021 00:01:03 -0600
Subject: [PATCH] Remove __attribute__((__gnu_inline__)) to allow compiler to
emit functions
The following example works with MSVC but will fail using the mi
20 matches
Mail list logo
