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 Zig user and I took u
On Thu, 22 Jul 2021, Jonathan Marler wrote:
The linker errors were found by a Zig user and I took up the challenge
to fix it (original issue
here: https://github.com/ziglang/zig/issues/9364)
Zig's using clang under the hood and on top of it, it adds automatic
dynamic compilation of various libc
The linker errors were found by a Zig user and I took up the challenge to
fix it (original issue here: https://github.com/ziglang/zig/issues/9364)
Zig's using clang under the hood and on top of it, it adds automatic
dynamic compilation of various libc implementations/bindings. For windows
it dyna
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 files in ming2-w64-crt. Thanks for the clarification.
Hmm, ok, that's definitely y
Thanks Martin,
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 files in ming2-w64-crt. Thanks for the clarification.
On Thu, Jul 22, 2021 at 3:33 AM Martin Storsjö wrote:
> On Wed,
On 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
order for these symbols to be available, don't
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 order
for these symbols to be available, don't they need to be in ws2_32.def? Is
that right?
Hi,
On Wed, 21 Jul 2021, LIU Hao wrote:
在 7/20/21 11:44 AM, Jonathan Marler 写道:
How's this?
Thanks for the update. I believe it's 100% safe, but let's have it in master
for a while and see whether something breaks.
Actually it turns out that this does break building mingw-w64-crt (at
le
在 7/20/21 11:44 AM, Jonathan Marler 写道:
How's this?
Thanks for the update. I believe it's 100% safe, but let's have it in master for a while and see
whether something breaks.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
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:
> >
> >
>
> Would you please send a new
在 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:
Would you please send a new patch as an attachment? This one seemed to be corrupted due to
hard-wrapping. Al
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
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.
Well even with static inline, their address can be taken just fine, it's
just not identical across all translation units. I don't see that a
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
在 7/13/21 6:33 PM, Martin Storsjö 写道:
It appears to fix the issue yes. Here's a patch with that solution:
`static inline` looks the safest solution, as long as the address of those
functions aren't taken.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signatur
On Tue, 13 Jul 2021, Jonathan Marler wrote:
I highly suggest you not play with this inline stuff. It's something very
fragile that works by
accident; any tiny change could be catastrophic.
Yeah this whole inline thing is a complete mess. But the headers are
currently broken with Clang, using
> I highly suggest you not play with this inline stuff. It's something very
fragile that works by
accident; any tiny change could be catastrophic.
Yeah this whole inline thing is a complete mess. But the headers are
currently broken with Clang, using any of those WS2TCP_INLINE functions
with clan
On Tue, 13 Jul 2021, LIU Hao wrote:
在 7/13/21 5:02 PM, Jonathan Marler 写道:
Thanks for the convenient info. However, when I try to use
__attribute__((__weak__)) I get a compiler warning from GCC, i.e.
extern __inline__ __attribute__((__weak__))
void foo(void) {}
int main(int a
在 7/13/21 5:02 PM, Jonathan Marler 写道:
Thanks for the convenient info. However, when I try to use __attribute__((__weak__)) I get a
compiler warning from GCC, i.e.
extern __inline__ __attribute__((__weak__))
void foo(void) {}
int main(int argc, char *argv[])
{
foo
在 7/13/21 3:05 PM, Jonathan Marler 写道:
+# if ((__MINGW_GNUC_PREREQ(4, 3) || defined(__clang__)) &&
__STDC_VERSION__ >= 199901L)
+# define __MSVC_INLINE extern inline
+# else
No this is not correct. MSVC `__inline` is the C++ `inline`, which is equivalent to `extern
__inline__ __attribute__((_
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: Jonathan Marler
Date
Hi Jonathan,
On Tue, 13 Jul 2021, Jonathan Marler wrote:
The problem here appears to be the inclusion of
`__attribute__((__gnu_inline__))` which is what
tells the compiler NEVER to emit the function definition. Removing this
attribute allows the compiler
to emit the function which allows its a
>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 mingw head
23 matches
Mail list logo
