[boost] libboost_fiber-mt.dll missing in mingw32 package #7071
Comments
|
This command compiles your code: |
I get the following error: |
|
Diffing both packages shows |
|
thread local storage seems to be misdetected for the fiber library, if you remove the requirement check for it in libs/fiber/build/jamfile.v2 it builds no problem. |
|
That sounds a bit like what happened with libstdc++ in #7043. |
|
That may very well be the case aye. |
lazka
changed the title
damn... |
|
google gives me this:
I guess confirming that the gcc bug still exists and report it in the bugtracker would be a good next step. |
|
That would probably be a good idea, though from what i can read at the gcc bug thread they allready had some idea how to fix it (trampolines) but it newer seems to have been applied. |
|
@Facon so looks like there is no easy fix. I'd advise you to work with the 64bit toolchain instead if possible. |
|
I reported the bug is still active to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 |
|
I see during boost 32 bit configure: |
|
In boost sources see: So it related to https://sourceforge.net/p/mingw-w64/bugs/527/ |
|
Been like this since forever and still not fixed, if it was as easy as the commenter in the gcc bug thread said it would have worked a long time ago, so i doubt we will ever see a fix to it unless someone comes up with a patch (it does not seem to be a main agenda for the gcc devs, as long as it works on linux). Might be better to get boost building with mingw clang instead. |
|
@revelator at least example from mingw-w64 bugreport dont crash for me |
|
It appears that, despite commit messages to the contrary, the __cxa_thread_atexit from mingw is being used rather than one from libstdc++, and this __cxa_thread_atexit is defined to take a __thiscall function pointer, not __cdecl. |
|
So the boost workaround no longer appllies ?. |
|
I think @Alexpux is one step ahead of you there 😁 |
|
If the mingw-w64 |
|
I haven't actually seen the destructor be called at thread exit, though. I stepped through the disassembly, and the tls value that mingw was storing its dtor list in was NULL at the time the tls_callback was called. I wonder if libgcc's was called first and cleaned up emutls before that. EDIT: this appears to be the case (3 == DLL_THREAD_DETACH): |
|
Neat 👍 |
…se the `__thiscall` calling convention for i686-w64-mingw32 The mingw-w64 implementations of `__cxa_thread_atexit()` and `__cxa_atexit()` have been using `__thiscall` since two years ago. Using the default calling convention (which is `__cdecl`) causes crashes as explained in PR83562. Calling conventions have no effect on x86_64-w64-mingw32. Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/crt/cxa_thread_atexit.c Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/f3e0fbb40cbc9f8821db8bd8a0c4dae8ff671e9f/ Reference: msys2/MINGW-packages#7071 Signed-off-by: Liu Hao <lh_mouse@126.com> 2020-10-08 Liu Hao <lh_mouse@126.com> libstdc++-v3: * libsupc++/cxxabi.h: (__cxa_atexit): mark with _GLIBCXX_CDTOR_CALLABI (__cxa_thread_atexit): ditto * libsupc++/atexit_thread.cc: (__cxa_atexit): mark with _GLIBCXX_CDTOR_CALLABI (__cxa_thread_atexit): ditto (elt): ditto
|
If you use clion, you can try change your toolchain to msys2 mingw. Don't use clion bundled mingw. |
|
Workaround available #7071 (comment) |
Hello everyone,
I would like to know how can I link a very simple application with boost fibers.
I am getting linking errors that says that fiber references are missing. I confirm that doing objectdump on all *.a doesn't show any reference to fiber's classes.
I show below files that I'm using.
CMakeLists.txt
src/sample.cpp
Linking error
The text was updated successfully, but these errors were encountered: