search

actions / runner-images

GitHub Actions runner images
MIT License
9.82k stars 3.01k forks source link

Windows build fails with runner image 20221120.1 #6627

Closed Albrecht-S closed 1 year ago

Albrecht-S commented 1 year ago

Description

We are using a tool (fluid-cmd.exe) which is created during the build and used later several times to convert fluid (.fl) files to source code (.h and .cxx). This tool fails with error code -1073741511 (hex C0000139).

I consider this a bug (regression of the runner image) because it worked flawlessly until Nov. 22 with the previous runner image (20221027.1).

Since Nov. 22 building with the old runner worked and some "random" builds with the new runner failed. Since today it seems that all builds fail with the new runner. See more info below. Current build fail/success can be viewed here: https://github.com/fltk/fltk/commits/master

Platforms affected

Runner images affected

Image version and build link

Runner Image

Failed build:

Latest successful build:

Successful build with runner image

Is it regression?

Yes. Works fine with image 20221027.1 (see above)

Expected behavior

We are using a tool (fluid-cmd.exe) which is created during the build and used later several times to convert fluid (.fl) files to source code (.h and .cxx). This tool should create the files and return no error as it did with runner version 20221027.1 (see above).

Actual behavior

This tool (fluid-cmd.exe) fails with the current runner image 20221120.1 with error code -1073741511. Excerpt from the build log:

Generating CubeViewUI.cxx, CubeViewUI.h
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(247,5): error MSB8066: Custom build for 'D:\a\fltk\fltk\test\CubeViewUI.fl;D:\a\fltk\fltk\test\CMakeLists.txt' exited with code -1073741511. [D:\a\fltk\fltk\build\test\CubeView.vcxproj]

Similar errors occur later for several other identical custom build steps.

It is noteworthy that we first got some intermittent build failures since Nov. 22, 2022 (first failed build) without changing anything related to the error. It appears that all failed builds were with the new runner version whereas the working builds were with the old runner version.

This makes it very likely that this is a regression in the runner image.

Repro steps

There's nothing I can provide here. A local build with Visual Studio 2019 works for me, others have reported that VS 2022 works as well.

Albrecht-S commented 1 year ago

Further information: as far as I found out here error code -1073741511 = hex C0000139 means:

0xC0000139 STATUS_ENTRYPOINT_NOT_FOUND {Entry Point Not Found} The procedure entry point %hs could not be located in the dynamic link library %hs.

This doesn't seem to be related to our build. See also above that this is very likely a regression and that it appeared only with the latest runner image.

igorboskovic3 commented 1 year ago

Hi @Albrecht-S , thank you, we will investigate.

igorboskovic3 commented 1 year ago

Hi @Albrecht-S can you provide minimal repro steps?

Albrecht-S commented 1 year ago

It's hard to say if I can do this because I don't know what is happening and I can't reproduce it on my local system. If my interpretation of the error code is correct (can you confirm this?) then the error message doesn't tell me which dll is the culprit. :-(

Anyway, I investigated on my local system (Windows 10 Home, Version 22H2, Build 19045.2311), if this is of any help. The tool we build (fluid-cmd) depends only on Windows system dll's. I built with VS 2019 in Release mode (the same as in the failed CI build process) and I'm using MSYS2 (ldd) only to list the linked dll's as shown here:

$ ldd Release/fluid-cmd.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7fffba5b0000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7fffb86b0000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7fffb7f60000)
        WS2_32.dll => /c/Windows/System32/WS2_32.dll (0x7fffba380000)
        gdiplus.dll => /c/Windows/WinSxS/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.19041.2251_none_91a40448cc8846c1/gdiplus.dll (0x7fff97270000)
        RPCRT4.dll => /c/Windows/System32/RPCRT4.dll (0x7fffb9860000)
        COMCTL32.dll => /c/Windows/WinSxS/amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.19041.1110_none_792d1c772443f647/COMCTL32.dll (0x7fff977e0000)
        ADVAPI32.dll => /c/Windows/System32/ADVAPI32.dll (0x7fffba2d0000)
        USER32.dll => /c/Windows/System32/USER32.dll (0x7fffb8c80000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x16bd6fa0000)
        win32u.dll => /c/Windows/System32/win32u.dll (0x7fffb7d80000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7fffba4d0000)
        GDI32.dll => /c/Windows/System32/GDI32.dll (0x7fffb9990000)
        combase.dll => /c/Windows/System32/combase.dll (0x7fffb8e30000)
        gdi32full.dll => /c/Windows/System32/gdi32full.dll (0x7fffb8340000)
        sechost.dll => /c/Windows/System32/sechost.dll (0x7fffb8b20000)
        msvcp_win.dll => /c/Windows/System32/msvcp_win.dll (0x7fffb84e0000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7fffb8240000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x16bd7150000)
        SHELL32.dll => /c/Windows/System32/SHELL32.dll (0x7fffb9ab0000)
        ole32.dll => /c/Windows/System32/ole32.dll (0x7fffb89f0000)
        COMDLG32.dll => /c/Windows/System32/COMDLG32.dll (0x7fffb8910000)
        shcore.dll => /c/Windows/System32/shcore.dll (0x7fffb9190000)
        SHLWAPI.dll => /c/Windows/System32/SHLWAPI.dll (0x7fffb8bc0000)
        VCRUNTIME140.dll => /c/Windows/SYSTEM32/VCRUNTIME140.dll (0x7fff9c090000)
        VCRUNTIME140_1.dll => /c/Windows/SYSTEM32/VCRUNTIME140_1.dll (0x7fffa0bc0000)

As you can see all DLL's are Windows system DLL's.

I could try to build a minimal reproducer but I have some questions:

  1. Is my assumption about the failure to load a dynamic link library (dll) correct?
  2. Could it be that the entry point of the main program fluid-cmd is not found despite the error description mentioning a dll?
  3. Is there anything like ldd (for instance dependency walker) available on the runner that I can use in a console (i.e. on the command line during the build process) to list dependencies of the fluid-cmd tool after building it?
  4. If yes, how would I invoke it? (Windows is not my usual system environment)
  5. Is it possible that something like a virus checker injects another dll which is the real culprit on the new runner image?
  6. Would it help if I could strip the build process so far down that only the minimal number of programs is built?

If you could answer my questions this could help me to get a minimal repro working.

The problem I see is that fluid-cmd itself needs the static FLTK libraries that are built before fluid-cmd is used. I could strip the build down that only the minimal number of libraries is built and fluid-cmd runs only once to build one example program. Would this be enough for a minimal repro?

Albrecht-S commented 1 year ago

FWIW: the program fluid-cmd.exe is a console program whereas fluid.exe is a Windows (GUI) program. Again using MSYS2 to show this:

$ file Release/fluid*.exe
Release/fluid-cmd.exe: PE32+ executable (console) x86-64, for MS Windows
Release/fluid.exe:     PE32+ executable (GUI) x86-64, for MS Windows
Albrecht-S commented 1 year ago

Short info: I found the culprit and I could fix it in our GitHub workflow file. But ...

Long info: It's a change in the GitHub runner that now includes image libraries (libjpeg, libpng) and zlib. These libs were found by our CMake configure process and obviously linked in fluid-cmd.exe (which is intentional). I assume further: when fluid-cmd.exe gets launched to generate necessary files it doesn't find the respective DLL's (not in PATH?).

The fix (workaround?) in our build instructions was to disable the system library search so it uses the internal, bundled libraries libjpeg, libpng, and zlib. In the previous runner image this was used as a fallback because the libs didn't exist.

Summary:

  1. I could work around the issue for us (FLTK) by disabling the library search for these libraries.
  2. I don't know why these libs are not found at runtime (fluid-cmd.exe).
  3. Point (2.) may be a PATH issue. Should this be fixed in the runner image?

For me this issue is resolved but it's still something you might want to investigate further. However, please feel free to close it.

FTR: the relevant part of the failed jobs is:

-- Found ZLIB: C:/Strawberry/c/lib/libz.a (found version "1.2.11") 
-- Found JPEG: C:/Strawberry/c/lib/libjpeg.a (found version "90") 
-- Found PNG: C:/Strawberry/c/lib/libpng.a (found version "1.6.37") 
-- Looking for png.h
-- Looking for png.h - found

What is this "Strawberry" thing? Looks like something related to perl ...

Anyway, just in case it's still of any value: I found this by reducing our build to a minimal process and eventually in the logs. The minimal build process can be found in my FLTK fork in branch github-minimal. Note that I will delete this branch as soon as this issue is closed.

Thanks for your investigation.

MikuAuahDark commented 1 year ago

We're also start hitting this issue where CMake starts picking libraries from C:/Strawberry which apparently doesn't match the OS-architecture, result in build failure.

For more reference, love2d/love@b738668e9c3ecca95d61b931478945ced4049923 compiles successfully, which is approximately 4 days ago. At the Windows configure step HarfBuzz and other libraries are NOT found when it configures our bundled FreeType, which is intended.

However less than hour ago (as of writing), we're hitting compile failure at love2d/love@659969783542a18325ab8794126f96e62e4c1d6a. At the configure step, CMake starts picking libraries from C:\Strawberry which is NOT what we want! Furthermore it always picks 64-bit libraries even when we're compiling for 32-bit, causing link errors down the road.

This could be a regression.

Flamefire commented 1 year ago

Yes it seems to be that recently the windows images (I noticed it on windows-2019) include StrawberryPerl installed in C:/Strawberry This seems to be a Perl distribution

However it contains binaries (executables and libraries) compiled with MSYS2 MinGW GCC which are incompatible with MSVC compiled object files/binaries. Or at least "sometimes".

E.g. libiconv from that distribution can be linked & used normally with MSVC except for the error case: The errno set in libiconv is a different location than what MSVC object files/binaries read.
I.e. libraries or executables built with MSVC and those that MinGW built (inside StrawberryPerl) cannot read the errno set by each other when linked together.

There may be other similar subtle differences where things "mostly work"

MikuAuahDark commented 1 year ago

In my case, I have to delete the whole C:/Strawberry folder for my build to work.

Failed build commit to test the CMAKE_IGNORE_PREFIX_PATH: MikuAuahDark/love2d@268a7d81d8f74200107447f81f542bba7bd0cf10

Flamefire commented 1 year ago

Together with my Boost colleague Peter Dimov we figured out what is going on: CMake was updated to 3.25 which includes a change to find *.a files when configuring for MSVC: https://gitlab.kitware.com/cmake/cmake/-/issues/23975

Summary:

The CMake maintainers are aware of the potential trouble that change might cause and included it in the release only "on watch", i.e. it is likely to be removed in the next CMake release as we now have evidence that this is actually an issue with Meson creating wrongly named files not with CMake not finding them and the change causes more trouble than it solves. See the linked issue for details.

A workaround is to pass -DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c to the cmake command which makes CMake ignore that prefix and avoids it finding e.g. C:/Strawberry/c/lib/libfoo.a (/lib is a suffix)

As @MikuAuahDark noticed this will still pick up C:/Strawberry/perl/bin/pkg-config.bat which will then find e.g. C:/Strawberry/c/lib/libharfbuzz.a.
After digging through the CMake source the pkg-config.bat is found by find_program which includes the entries from $PATH as search paths. I.e. adding C:/Strawberry/perl to CMAKE_IGNORE_PREFIX_PATH is not enough, as that is not used as a "prefix" (with "/bin" as suffix) in CMake terms but C:/Strawberry/perl/bin being in $PATH is used directly.

So -DCMAKE_IGNORE_PATH=C:/Strawberry/perl/bin would need to be used to avoid it finding ANY binaries in that path or maybe -DCMAKE_IGNORE_PATH=C:/Strawberry/c/lib instead of the CMAKE_IGNORE_PREFIX_PATH may be enough to exclude any libraries in that folder as even for the libraries and paths returned by pkg-config.bat a find_library call is done. But again on the full path (as returned by pkg-config) so CMAKE_IGNORE_PREFIX_PATH will not apply but very likely CMAKE_IGNORE_PATH will.

Albrecht-S commented 1 year ago

@Flamefire Thank you very much for your analysis and for posting your results here. I appreciate this very much.

h-vetinari commented 1 year ago

Proper solution would be: https://github.com/actions/runner-images/issues/5459

strawberry perl should just be shunned for its deployment practices, or - at the very least - patched to not gratuitously inject a broken toolchain into PATH. Upstream strawberry is stubbornly refusing to do this: https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11

Flamefire commented 1 year ago

To be fair: Perl needs a working compile environment to fully function, hence StrawberryPerl has a good reason to bundle a toolchain which is accessible when Perl is accessible (which is the case for the default installation, but only on request for the "portable" installation as they mention), so no, they do not "inject a broken toolchain into PATH"

The toolchain they "inject" works very well. It is only that you must not combine MSVC ABI binaries and GNU ABI binaries. So someone using the GNU ABI binaries from StrawberryPerl with MSVC makes a mistake.

To avoid this the practice was that GNU ABI import libraries had the extension *.awhile MSVC ABI import libraries had the extension *.lib.
However this creates trouble when trying to distribute static and dynamic libraries on Windows as Windows static libraries also have the extension *.lib which seems to be why Meson chose to break this convention and name MSVC ABI import libraries *.a which CMake then chose to find.

So if you want to blame someone then the people responsible for naming both static and import libraries the same on Windows.

Everything else (i.e. all the tools mentioned) just tried to provide the best user experience given that situation.

So for a "proper solution" I'd suggest to use the portable StrawberryPerl or any other means such that Perl is available on request only on GHA images or simply use -DCMAKE_IGNORE_PATH=C:/Strawberry/perl/bin;C:/Strawberry/c/lib in the configure command when configuring for MSVC. In the end CMake is meant to be passed additional arguments when the default happens to guess something wrong as there is never a one-size-fits-all.

I hope that helps to understand why this issue is difficult and how seemingly good decisions led us to this situation and it is hard to tell which decision is now to blame as each one is "right" given the technical reasons.

eli-schwartz commented 1 year ago

To be fair: Perl needs a working compile environment to fully function, hence StrawberryPerl has a good reason to bundle a toolchain which is accessible when Perl is accessible (which is the case for the default installation, but only on request for the "portable" installation as they mention), so no, they do not "inject a broken toolchain into PATH"

This is fallaciously wrong (although the propaganda comes from the Strawberry devs -- do not believe everything you read).

Perl does not need a working compile environment to fully function -- perl.exe is needed to fully function -- but it may be needed internally by module building routines launched via perl.exe in the event that people both need a functioning perl and a functioning CPAN.

A functioning CPAN is not a worthwhile tradeoff for Github Actions to make, when this doesn't just break recent versions of cmake -- it breaks any build system that notices GCC and assumes it is supposed to build with GCC instead of MSVC. GCC is in PATH while MSVC needs to be configured with something like https://github.com/ilammy/msvc-dev-cmd, and some build systems like Meson will also try to set up an MSVC dev environment for you -- but not if GCC is detected first.

Strawberry Perl has a solution for that, you can select at installation time to simply not add its mingw userland to the PATH. Actual Perl users possess the domain specific knowledge of Perl to add the extra path in if they actually need to go building PerlXS modules. People who have never heard of Perl in their lives have to play "hunt the weird bug", then learn what Perl is, and why they don't care about it, and then add Perl-specific workarounds like deleting C:\Strawberry at the beginning of their workflows. People who have heard of Perl but don't use it can skip the "learn what Perl is" step.

Strawberry Perl does NOT have a solution for pkg-config.bat shipping alongside perl.exe -- the only solution is to get rid of perl altogether (or find a different Perl distributor, maybe ActivePerl?) but that's not such a big problem as all that.

Everything else (i.e. all the tools mentioned) just tried to provide the best user experience given that situation.

Except for Strawberry Perl, which is uninterested in the best user experience for anything other than Strawberry Perl.

Which isn't totally strange, because this mostly breaks for people who didn't want to install perl at all, but had it baked into the Github Actions VM image -- and sometimes, had it recommended in the OpenSSL build instructions as a good place to get a perl.exe interpreter. The broken experiences don't happen to the Strawberry Perl target userbase -- just the Github target userbase. :rofl:

mikhailkoliada commented 1 year ago

Hello!

Just few observations from me:

  1. there were no changes to strawberry perl we install (we do it from choco and no new releases or formula changes)
  2. there were no changes in mingw version we install (we pin the specific version and also no changes were made to that release) So my only guess right now is something got changed in cmake itself
Flamefire commented 1 year ago

Perl does not need a working compile environment to fully function -- perl.exe is needed to fully function -- but it may be needed internally by module building routines launched via perl.exe in the event that people both need a functioning perl and a functioning CPAN.

That's what I meant by "fully function".

it breaks any build system that notices GCC and assumes it is supposed to build with GCC instead of MSVC

I wouldn't say it "breaks" because as far as I understood using the StrawberryPerl GCC with the StrawberryPerl libraries works as they are ABI compatible (obviously).
Build systems make a best guess on what to use. If a user wants to not let it guess than one has to tell the build system.

But cmake is still broken in its handling of Strawberry pkg-config.

If you wanted to use the StrawberryPerl GCC with CMake then it does the right thing. If you don't want to use what is in the environment and hence auto-detected then you can tell CMake to ignore certain paths (see above how to do that) or not add the PATHs in the first place (see my recommendation about the "portable installation" of StrawberryPerl)

My understanding is that cmake prefers to avoid pkg-config because pkg-config isn't turing complete

CMake has other means of finding stuff (CMake configs, Find-Modules) so it does not need pkg-config for most things.

@eli-schwartz Don't get me wrong: I was also bitten by this change in CMake and had lost hours trying to understand what is happening. I'm just trying to understand why things are as they are, what has changed to lead to the situation and what the reasons for decisions (which seem to be right in isolation) were.

Except for Strawberry Perl, which is uninterested in the best user experience for anything other than Strawberry Perl.

You could say the same about Meson creating MSVC ABI *.a import libraries while everything else is using *.lib files so the situation of mixing MSVC ABI with GNU ABI didn't occur. Of course at the expense of having trouble to distribute static and import libraries (as both are named *.lib) so others prior to that have opted to e.g. suffix the base name (e.g. libfoo_static.lib)

Again: I do understand the reasons of Meson for that change and they added a workaround especially for StrawberryPerl as they seemingly noticed the issue. It is only now the situation they you cannot have Meson, CMake and StrawberryPerl all in use at the same time with all features. (And maybe other distributions of MinGW toolchains not using the shell-environment approach)

@mikhailkoliada

there were no changes in mingw version we install

This is about the MinGW inside StrawberryPerl: It comes with a full MSYS2 toolchain to be able to build Perl modules if a user needs to.

So my only guess right now is something got changed in cmake itself

Correct: CMake 3.25 now finds *.a files in addition to *.lib files which breaks when building with MSVC and it happens to find GNU ABI *.a import libraries (which it does: Inside StrawberryPerl)

Albrecht-S commented 1 year ago

@mikhailkoliada: So my only guess right now is something got changed in cmake itself

@Flamefire Correct: CMake 3.25 now finds .a files in addition to .lib files which breaks when building with MSVC and it happens to find GNU ABI *.a import libraries (which it does: Inside StrawberryPerl)

To be precise: CMake 3.25.0 added support for .a import libraries but this will be reverted in CMake 3.25.1 as Brad King (CMake maintainer) confirmed. The git commit doing this has just been merged.

@mikhailkoliada I see two (three) options to proceed for the current Windows runner images:

  1. downgrade CMake to the version of the previous image (3.24.x) or
  2. wait until CMake 3.25.1 is released and update the runner image(s) ASAP
  3. not really: patch CMake (see linked CMake merge request) and install this in the Windows runner image(s)

I could see that the relevant CMake milestone is due on Nov 30 which is very soon now but unfortunately I don't know of a release schedule, i.e. how long it will take until 3.25.1 will be released.

MikuAuahDark commented 1 year ago

My understanding is that cmake prefers to avoid pkg-config because pkg-config isn't turing complete, so it probably affects fewer people.

While it's true CMake does not use pkg-config by default, other third-party-written CMake script still can run pkg-config if it founds them (e.g. SDL and FreeType), complicating things further. CMake provides module to deal with pkg-config, but user can of course ignore this and proceed to execute pkg-config directly through CMake execute_process, bypassing CMake module altogether.

nirbheek commented 1 year ago

that this is actually an issue with Meson creating wrongly named files not with CMake not finding them

The naming was picked on purpose: https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa

The actual indicator for whether two libraries are compatible is not GNU vs MSVC, but "what CRT is being used". If both GCC-built (or clang-built) and MSVC-built libs are using UCRT, it's fine to link them. The filename suffix is a poor substitute for that, especially since MinGW now defaults to UCRT, same as MSVC.

Flamefire commented 1 year ago

The actual indicator for whether two libraries are compatible is not GNU vs MSVC, but "what CRT is being used". [...] The filename suffix is a poor substitute for that, especially since MinGW now defaults to UCRT, same as MSVC.

One could argue that the used CRT is part of the ABI, but the distinction doesn't really matter anyway. Point is: MinGW may or may not create libraries compatible with MSVC and there is a need to distinguish that when you want to use both or happen to have both installed.

As Brad King wrote:

A widely used convention [for MSVC compatible library files] is to use foo.{lib,dll} for the shared library and libfoo.lib for the static library.

Anyway that is offtopic for this issue: I agree with @Albrecht-S to upgrade the runners to CMake 3.25.1 ASAP and user may use CMAKE_IGNORE_PATH in all cases to exclude StrawberryPerl libs when those are not wanted. Again: You could use CMake to use the StrawberryPerl GCC and libs to build a fully functional exe (I guess)

nirbheek commented 1 year ago

Anyway that is offtopic for this issue

Perhaps, but there is a strong argument that Strawberry Perl's pkg-config should not be in PATH by default on GHA images, because that implies that everyone who can detect libs with pkg-config wants to use Strawberry Perl's libs, which is overwhelmingly not the case. The majority of people who use Strawberry Perl will use it for the perl interpreter, not the pkg-config.

This is the Nth breakage caused by this. See also: https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11

Flamefire commented 1 year ago

Perhaps, but there is a strong argument that Strawberry Perl's pkg-config should not be in PATH by default on GHA images, because that implies that everyone who can detect libs with pkg-config wants to use Strawberry Perl's libs, which is overwhelmingly not the case.

Unfortunately it is an all-or-nothing. Again: obviously debatable; but from GHAs point of view having StrawberryPerl but stripping of some paths so only using a part of it is not a good approach as it may again be confusing for others. See e.g. this comment:

However, some FFI modules and others will misbehave if there's no compiler available. https://metacpan.org/pod/FFI::Platypus::Bundle for example

Hence I'd go with the portable approach where users of Perl need to load a file or set paths manually: https://github.com/StrawberryPerl/Perl-Dist-Strawberry/issues/11#issuecomment-674343643

Or have something like https://github.com/actions/setup-python to load that file for Perl users.

nirbheek commented 1 year ago

Hence I'd go with the portable approach where users of Perl need to load a file or set paths manually

Yeah, I think that would be a good solution.

mikhailkoliada commented 1 year ago

I see that cmake 3.25.1 has been released which contains the fix. So it will be updated in the images next week

eli-schwartz commented 1 year ago

I wouldn't say it "breaks" because as far as I understood using the StrawberryPerl GCC with the StrawberryPerl libraries works as they are ABI compatible (obviously). Build systems make a best guess on what to use. If a user wants to not let it guess than one has to tell the build system.

But normally a build system is supposed to be able to guess well (that is why people make build systems, to do things for them) which is why build systems allow guessing in the first place. There's a reasonable assumption that your environment should only contain sensible things which you intended to install. Strawberry Perl breaks this -- and breaks the build by by successfully building invalid products which cannot be used for what you tried running a build system in order to do -- by injecting Strawberry GCC into your PATH when you're trying to develop with MSVC.

Arguing that it isn't broken because the compiler you didn't want to compile with is compatible with the library you didn't want to compile against, seems to be missing the point.

If you wanted to use the StrawberryPerl GCC with CMake then it does the right thing. If you don't want to use what is in the environment and hence auto-detected then you can tell CMake to ignore certain paths (see above how to do that) or not add the PATHs in the first place (see my recommendation about the "portable installation" of StrawberryPerl)

I think we probably agree that it's a bad idea for Github to add the PATHs in the first place, yeah.

You could say the same about Meson creating MSVC ABI *.a import libraries while everything else is using *.lib files so the situation of mixing MSVC ABI with GNU ABI didn't occur. Of course at the expense of having trouble to distribute static and import libraries (as both are named *.lib) so others prior to that have opted to e.g. suffix the base name (e.g. libfoo_static.lib)

I don't think this is the best comparison. :)

I say that Strawberry Perl is "uninterested in the best user experience for anything other than Strawberry Perl" because:

However, Meson's decision was made based on the understanding that it is useful for autotools, cmake, and Visual Studio users, not just Meson users. In fact, per @nirbheek's elaboration above, it is probably still the correct decision, because autotools, meson, and even cmake will produce MSVC-ABI libraries using the .a and .dll.a convention, and people should be able to link with them -- which is why Meson looks for them, will continue to look for them, and hasn't had issues like the recent cmake fallout.

Whether one agrees or disagrees with that assessment, it's certainly true that Meson cares about the experience of cmake and cmake users. And I agree that as cmake stands today, it's too much of a regression to simply flip a switch and check for these libraries. Reverting the cmake commit was the right move.

(But I think that cmake should be able to handle the situation correctly for MSVC-ABI libraries built with mingw GCC and the UCRT, and in the long run, cmake should still be looking for them.)

And we aren't going to avoid discussing the topic, or lock mesonbuild tickets when people try to question our decision. :p

...

Point is, that Strawberry Perl leaves the collective software community with our hands tied, there's no choice other than to not use it (and the runner image currently makes us use it by default). There's nothing else to discuss and nowhere to discuss it.

Again: You could use CMake to use the StrawberryPerl GCC and libs to build a fully functional exe (I guess)

Again: this is technically true by the dictionary definition of "functional" -- it does something when you run it -- but it does not function the way even a single user anywhere wants it to.

This toolchain exists solely for building PerlXS modules, it exists internally to Strawberry Perl, and it unpredictably contains whatever Strawberry Perl currently believes is necessary for PerlXS and PerlXS alone.

eli-schwartz commented 1 year ago

Or have something like https://github.com/actions/setup-python to load that file for Perl users.

I absolutely agree 100% -- this would be a beautiful solution. People who want perl.exe would have to explicitly ask for it, but Github would distribute it in the VM images and make it easy to load it. It's nice to have software that is so preinstalled that you don't even need to ask for it before running it, but sometimes that conflicts with other software and you just have to ask for it before using it.

mikhailkoliada commented 1 year ago

Cmake version updated

paroj commented 1 year ago

this is still an issue when building python wheels, as they will pull cmake from https://pypi.org/project/cmake/, which is still at 3.25.0.

MikuAuahDark commented 1 year ago

You need to contact the package maintainer of such package. GitHub Actions is already correct. https://github.com/scikit-build/cmake-python-distributions

eli-schwartz commented 1 year ago

:thinking: What if...

... maybe...

... Github Actions stopped configuring their Perl installation to leak dangerous gcc.exe executables, dangerous pkg-config.bat executables, and deadly lib/ and include/ directories all over the PATH?

As stated above, these all cause numerous issues, and it's never actually right to use them. CMake is just one more recent example of the breakage caused by installing Perl like this.

Please, can we fix the root of the problem by fixing Github Actions?