Description of problem: TBH, I'm not sure if it is the right component to report for. Anyway, if I compile a simple Boot.Log program with F38's MingGW64, I can run the program with WINEPATH set to mingw's sysroot bin directory: export WINEPATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin wine test.exe It runs fine. However, if I want to deploy the program, I put all .dll dependencies including boost dlls into a dir (e.g. myapp). However, the program doesn't successfully run and it hangs (apparently, is a deadlock.as also reported by wine about a locked thread). Now, if I only remove libssp-0.dll from the dir, it works fine again: cd myapp export WINEPATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin rm libssp-0.dll wine test.exe I'm not sure, but looks like that whenever libssp-0.dll is loaded anywhere except the default path, it cause deadlock. Version-Release number of selected component (if applicable): mingw64-boost-1.78.0-4.fc38.noarch How reproducible: 100% Steps to Reproduce: 1. Create the following file as test.cpp: #include <boost/log/trivial.hpp> int main(int, char*[]) { BOOST_LOG_TRIVIAL(trace) << "A trace severity message"; BOOST_LOG_TRIVIAL(debug) << "A debug severity message"; BOOST_LOG_TRIVIAL(info) << "An informational severity message"; BOOST_LOG_TRIVIAL(warning) << "A warning severity message"; BOOST_LOG_TRIVIAL(error) << "An error severity message"; BOOST_LOG_TRIVIAL(fatal) << "A fatal severity message"; return 0; } 2. Compile with: $ x86_64-w64-mingw32-g++ test.cpp -lboost_log-mt-x64 -DBOOST_ALL_DYN_LINK 3. Run: $ export WINEPATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin $ wine a.exe 4. It runs successfully. Now, run: $ unset WINEPATH $ cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/*.dll . $ wine a.exe Actual results: In step 4, you'll see the app hangs and you should kill it to terminate: $ wine a.exe 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.14 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 0088:fixme:wineusb:query_id Unhandled ID query type 0x5. 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 MESA-INTEL: warning: Haswell Vulkan support is incomplete MESA-INTEL: warning: Haswell Vulkan support is incomplete 0114:err:sync:RtlpWaitForCriticalSection section 00000001CCDFD010 "?" wait timed out in thread 0114, blocked by 0000, retrying (60 sec) If you only remove libssp-0.dll from current directory and export WINEPATH to point to the installed one, it works fine again. Expected results: $ wine a.exe 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.14 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 0088:fixme:wineusb:query_id Unhandled ID query type 0x5. 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 MESA-INTEL: warning: Haswell Vulkan support is incomplete MESA-INTEL: warning: Haswell Vulkan support is incomplete [2023-08-27 18:47:12.922807] [0x00000114] [trace] A trace severity message [2023-08-27 18:47:12.930604] [0x00000114] [debug] A debug severity message [2023-08-27 18:47:12.939153] [0x00000114] [info] An informational severity message [2023-08-27 18:47:12.947407] [0x00000114] [warning] A warning severity message [2023-08-27 18:47:12.956964] [0x00000114] [error] An error severity message [2023-08-27 18:47:12.966910] [0x00000114] [fatal] A fatal severity message $ To be honest, I'm not sure if the problem really is related to libssp-0.dll, but this is what changes everything about this problem.
Just a note: the problem is weird. It happens even in the below code where 'myget' won't be called at all. But if you comment the use of logger_type or replace it with another type like int, it'll run fine!!: #include <boost/log/trivial.hpp> #include <iostream> using namespace std; auto& myget() { boost::log::trivial::logger_type lg; return lg; } int main(int, char*[]) { try { cout << "HIHIHIHI " << endl; return 0; } catch(...) { auto &f = myget(); } return 0; }
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.