Closed Schneegans closed 1 year ago
Totals | |
---|---|
Change from base Build 3513272209: | 0.0% |
Covered Lines: | 491 |
Relevant Lines: | 16734 |
@JonasGilg: Do you have an idea what could be going on here? The windows builds suddenly started to find some weird version of freeglut (see here: https://github.com/cosmoscout/cosmoscout-vr/actions/runs/3572835896/jobs/6006182952#step:6:59). Now I tried to modify our find script so that it does not look into system paths and it finds the correct version again (https://github.com/cosmoscout/cosmoscout-vr/actions/runs/3574455560/jobs/6016382446#step:6:59). However, now the CI job fails to execute the cosmoscout.exe
(https://github.com/cosmoscout/cosmoscout-vr/actions/runs/3574455560/jobs/6016382446#step:7:8).
If I convert the exit code to HEX (C0000139), it becomes the code for "entry point not found". It can't load one of the DLLs. Could it be, that it still tries to load the Starberry Freeglut DLL, which was compiled with a different MSVC version?
Here's the issue: https://github.com/actions/runner-images/issues/5459
Having an entire MinGW distribution in the PATH causes all sorts of problems depending on DLL search path order and files being searched for. I have seen problems due to Strawberry Perl pop up consistently, from linkers picking up incompatible libraries, but also hard-to-debug application crashes because executables loaded some incompatible DLL from the Strawberry Perl path. Even CMake is configuring Strawberry Perls libraries when compiling for MSVC
I am not sure how to fix this though. Mybe try to remove the Strawberry Perl?
Following this discussion: https://github.com/actions/runner-images/issues/6627, it seems that this issue may get fixed in the coming week.
I am closing this as this will be fixed automatically.
The windows CI finds the wrong version of glut. This attempts to fix this...