GitHub Actions (CI): failed Windows builds

[Albrecht Schlosser]

Hi Devs (and others),

we are experiencing failed Windows builds in our automatic (GitHub actions) build process.

tl;dr: I opened a GitHub bug report: https://github.com/actions/runner-images/issues/6627


These failed builds occurred first on Nov. 22 (intermittently) and seem to happen regularly (i.e. always) since today. I tracked it down to a new GitHub runner image (see report) that happened to be used randomly during the last two days and obviously always since today.

You can follow the bug report (link above) and I will report here when I will get noteworthy news.

Hopefully this will be fixed soon because I don't think that we can do anything about it. The only alternative would be to go back to an older GitHub runner (with VS 2010) but I don't want to do that.

FWIW: the build of the library still works fine (you can see compiler warnings etc.) and other builds (Linux, macOS) are not affected.

Albrecht

[Albrecht Schlosser]

On 11/24/22 16:15 Albrecht Schlosser wrote:
> ... an older GitHub runner (with VS 2010) ...

Correction: should read "VS 2019"

[imacarthur]

Bit of an outside chance (i.e. probably not) but I wonder if this is in someway related to the way that fluid-cmd chokes under Msys/mingw builds sometimes?

If so, we could try reverting to using "fluid -c" to perform the github actions and see if that is any more stable? 

We probably do not care if the instance of fluid we actually use supports a console shell or not, when performing the actions, so it would be "just the same"?

 

[Albrecht Schlosser]

On 11/24/22 16:15 Albrecht Schlosser wrote:

Hi Devs (and others),

we are experiencing failed Windows builds in our automatic (GitHub actions) build process.

tl;dr: I opened a GitHub bug report: https://github.com/actions/runner-images/issues/6627


These failed builds occurred first on Nov. 22 (intermittently) and seem to happen regularly (i.e. always) since today. I tracked it down to a new GitHub runner image (see report) that happened to be used randomly during the last two days and obviously always since today.

You can follow the bug report (link above) and I will report here when I will get noteworthy news.

OK, this is fixed now.

It was caused by incompatible image libraries (libjpeg, libpng, and/or zlib) included in the "new" GitHub runner image. Our build used these libs because it was not configured to use the local libs to build fluid and fluid could not be executed because of these incompatible libs (dll's). Disabling the system libs via CMake options fixed this issue for us.

I fixed it in:

commit c1a7c4af042a593b4b3a1df3e750b0cc80362486
Author: Albrecht Schlosser <albrechts.fltk@...>
Date:   Fri Nov 25 17:24:18 2022 +0100

    Fix GitHub Actions (CI) for Windows builds
    
    This was necessary because the latest GitHub "runner" image (20221120.1)
    includes incompatible image libs (libjpeg, libpng, and zlib). This
    caused `fluid-cmd.exe` to fail with error code -1073741511. For further
    information please refer to this GitHub Issue:
      https://github.com/actions/runner-images/issues/6627
    
    The previous runner version (20221027.1) did not include these libs
    and our build used the internal libs and worked.
    
    The fix is to disable the search for system libs in CMake.
    
    Note: this does not explain *why* these libs are incompatible.

I'm not going to investigate further why these libs are incompatible -- at least not now.

[melcher....@googlemail.com]

Wow, great work in finding this.

If we are using the host's libraries, do we also use the host's include files? If yes, why would there incompatibilities?

[Albrecht Schlosser]

Basically there is a possibility that there are incompatibilities
because our code might expect some features that are not (or no longer)
in the respective headers. If the host has another (older or newer)
version - most obvious a new major version - then this can happen.
However, then it would be very likely that it doesn't compile or can't
be linked. Neither of these possibilities was the case here.

Meanwhile I believe that my wording "incompatible" was not correct. I
came to the conclusion that we can compile and link but - unfortunately
- we link against DLL's and then - I assume! - one or more of these
DLL's is not found at runtime, hence the error message. Or maybe
*another* incompatible system DLL is found, or whatever. Unfortunately
Windows doesn't tell us which DLL can't be loaded.

Thus I decided to fix it by disabling system (image + z) libraries which
has the additional advantage that our bundled libs are built as well in
this CI run (as it was before).

I think that the fact that we can compile and link against some DLL's
(which are in non-system locations, BTW) is "normal" but then these
DLL's have to be somewhere in the PATH or the directory of the
executable. This seems to be the most plausible explanation.

[Bill Spitzak]

This use of local versions is only being done on Windows, correct?

I really don't like this as we absolutely should be using the installed libraries if at all possible, even on Windows. At minimum something needs to be done so that the local header files are not used if fltk is built using installed libraries.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/da1245fe-3ed3-6f4a-203d-80586aeb7a68%40online.de.

[Albrecht Schlosser]

On 11/25/22 21:02 Bill Spitzak wrote:

This use of local versions is only being done on Windows, correct?

Bill, this thread is about the CI builds on GitHub, aka GitHub Actions. We have no choice to select which software is installed on these systems. Since we need `fluid` to build and run to generate headers and sources of test apps we must take care that it works even on these CI systems. But this is *only* the case for CI builds.

Users can do whatever they want, be it Windows or not.

However, there *can* be a reason to force using the bundled libs: if the system libs *are* not compatible with the code FLTK uses.

I really don't like this as we absolutely should be using the installed libraries if at all possible, even on Windows. At minimum something needs to be done so that the local header files are not used if fltk is built using installed libraries.

That's all done, no problem.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/CAL-8oAjcf1CPuTo7z2_ENC7tCgj8oi2XkCdhsd4UWgohZJN1uw%40mail.gmail.com.