Repository navigation
Conversation
|
@QuasarAppCI the windows tests is not passed |
| arch: 'win64_llvm_mingw' | ||
| arch: 'win64_mingw' | ||
| cache: true | ||
| tools: 'tools_llvm_mingw1706' |
There was a problem hiding this comment.
this is wrong fix. you need to add just a EXPORT symbols.
|
@QuasarAppCI for windows the library and them tests should build only as shared library. |
…atic archives" This reverts commit 52b8ae8.
Adds HEARTSHARED_EXPORT to the remaining public classes (APIVersionParser, BigDataWraper, CachedDbObjectsRequest, CustomDBRequest, DataPack, DBObjectsRequest, DBObjectsRequestWithStream) so their symbols are exported from the Heart shared library and fix the Windows __imp_ link errors.
Per review: use a shared build on Windows (-DBUILD_SHARED_LIBS=ON) and stage Heart.dll, QuasarApp.dll and crc.dll next to HeartTest.exe before running the tests.
|
also use ccache to speedup build for all platforms |
|
Added ccache for all platforms (4c58a38): Linux via apt, Windows via pinned ccache 4.14.1 release, CMake compiler launchers enabled, and the cache is persisted across runs with actions/cache. CI is green on both platforms — 7/7 tests passed: https://github.com/QuasarApp/Heart/actions/runs/38141509482 |
|
@QuasarAppCI all issues is not solved yet - please see my preview messages |
Install CQtDeployer with QuasarApp/cqtdeployer-install-action so the 'test' target generated by addTests can deploy and run the tests. Replace the direct HeartTest binary invocation with 'cmake --build build --target test', letting CQtDeployer stage all runtime libraries. Replace the manual ccache installation with hendrikmuhs/ccache-action@v1.2. Addresses the maintainer review comments on PR #89.
|
Applied the requested changes:
CI is running on both platforms. |
CQtDeployer's Windows release is a GCC-MinGW build (imports libstdc++-6/libgcc_s_seh-1) that crashes with 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND) when the runner only provides the Clang/llvm-mingw + Strawberry MinGW runtimes. Restoring win64_mingw + tools_mingw1310 (the toolchain CQtDeployer's own CI uses to run cqtdeployer) makes the deploy/test targets work. The Heart project already builds and passes its qTests under win64_mingw (run 38133462181).
|
@QuasarAppCI for tests will be beter remove --parallel option |
…MSVCRT tools_mingw1310
Signed-off-by: Andrei Yankovich <EndrIIMail@gmail.com>
EndrII
left a comment
There was a problem hiding this comment.
thansk, but about your cqtdeployer windows build - it looks as issue of cqtdeployer tool. please create a issue about that in cqtdeployer repository
|
CI is green on all platforms (run 38151982282, 7/7 tests pass on Windows). Recording the root cause of the Windows CQtDeployer crash so the workaround step is self-explanatory in the workflow: the released Windows CQtDeployer bundle is internally mixed — CQtDeployer.exe and Qt6Core.dll are built with the MSVCRT MinGW, but the bundled libstdc++-6.dll / libgcc_s_seh-1.dll / libwinpthread-1.dll are from a UCRT MinGW, so cqtdeployer.exe dies at startup with 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND). The workflow now overwrites those three DLLs with the MSVCRT versions aqt ships under %IQTA_TOOLS%\mingw1310_64\bin before the deploy step. A permanent fix would belong in the CQtDeployer release packaging (ship a self-consistent MSVCRT bundle); once that lands the Windows fix step can be dropped. |
please create issue with that in cqtdeployer repository |
|
Done: filed QuasarApp/CQtDeployer#855 with the root-cause analysis (mixed MSVCRT/UCRT MinGW runtimes in the Windows release bundle), repro steps, the current workaround, and a suggested fix. Labels: Bug, Windows. |
Closes #87. Implemented automatically by Quasar agent.