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? 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ö <[email protected]> wrote: > 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 > least with Clang), with errors like these: > > ../libsrc/ws2tcpip/in6_addr_equal.c:9:5: error: redefinition of > 'IN6_ADDR_EQUAL' > int IN6_ADDR_EQUAL(const struct in6_addr *a,const struct in6_addr *b) > ^ > > /home/martin/fate/llvm-mingw/prefix/i686-w64-mingw32/include/ws2ipdef.h:244:21: > note: previous definition is here > WS2TCPIP_INLINE int IN6_ADDR_EQUAL(const struct in6_addr *a, const struct > in6_ad > dr *b) { > ^ > 1 error generated. > > > So given that, I think we need to revert this for now and get back to the > drawing board with this change. > > > Is the case that some of the functions listed as inline don't exist as > non-inline versions in the library? In that case, the fix would be to make > those individual ones available as non-inline too. > > > But the error case that was quoted before, IN6_IS_ADDR_UNSPECIFIED, is > defined in mingw-w64-crt/libsrc/ws2tcpip/in6_is_addr_unspecified.c. So is > the issue that that particular function doesn't actually end up included > in the right library, even though it exists in source? Doesn't seem so - I > do get the IN6_IS_ADDR_UNSPECIFIED symbol in libws2_32.a. > > > So, is the actual root issue that you're trying to fix, that you could get > away with using IN6_IS_ADDR_UNSPECIFIED without linking -lws2_32 with GCC? > So the function is made available in headers, but with attributes saying > the compiler is entirely free to use a non-inline version if the compiler > feels like it? And some project out there has implicitly started relying > on this being inlined, without linking with the relevant library? In that > case, the proper fix would be to actually link with the library. > > > // Martin > _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
