Replace Mono.Posix.NETStandard with Mono.Unix

[Numpsy]

Description

A test followup to #2780, in the hope that replacing the old Mono.Posix.NetStandard with the newer Mono.Unix will work better on ARM macs and help get the CI builds working again.
(I don't have an ARM mac to test with, so I'm guessing at some of this)

[Numpsy]

The way that the macOS tests timing out causes the Linux tests to abort is ever so slightly not helpful :-(

[xperiandri]

I have Mac M2. Do I just need to build and check if the build succeeds?

[xperiandri]

Why does it try to find something from net8.0 on CI?

[xperiandri]

Maybe we need this on CI?
https://github.com/fsprojects/FSharp.Data.GraphQL/blob/4392616de6b3f427bf68d925b078e959658250ed/.github/workflows/publish_ci.yml#L32

[Numpsy]

I have Mac M2. Do I just need to build and check if the build succeeds?

Some of the integration tests seem to be getting an exception thrown from

FAKE/src/app/Fake.DotNet.Cli/DotNet.fs

Line 839 in 3f98e8d

Mono.Unix.UnixPath.GetRealPath(dotnetTool) |> Path.GetDirectoryName

on the macOS runner. Maybe try calling that on an ARM mac and see if it works?

This change seems to avoid that error, though the CI run still fails.

[Numpsy]

I tried another build with a longer timeout at https://github.com/Numpsy/FAKE/actions/runs/9537030314 and the Windows run passed, but macOS and Linux both timed out running the integration tests, not sure why that is.

Why does it try to find something from net8.0 on CI?

Looks like some of the NuGet packages that it's installing have .NET 8 libs in them now and that causes warnings due to the old version of Paket in use, I don't know besides that.

[xperiandri]

I had the same until I applied my fix above

[Numpsy]

Hmm, looking at the CI logs for the mac build in more detail I see there's also this

DllNotFoundException: Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libSQLite.Interop.dll, 0x0001): tried: 'libSQLite.Interop.dll' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibSQLite.Interop.dll' (no such file), '/usr/lib/libSQLite.Interop.dll' (no such file, not in dyld cache), 'libSQLite.Interop.dll' (no such file), '/usr/local/lib/libSQLite.Interop.dll' (no such file), '/usr/lib/libSQLite.Interop.dll' (no such file, not in dyld cache)

from the issue #2007 - native libs work, so maybe that's another issue with a native lib on the ARM host?

[xperiandri]

I thought it runs on x64 on CI

[Numpsy]

I thought it runs on x64 on CI

The macOS-Latest runners are now using M1 CPUs - one of the effects of #2773 is to put in back to the older runners on Intel CPUs

[Numpsy]

Why does it try to find something from net8.0 on CI?

Actually, the integration tests at

FAKE/src/test/Fake.Core.IntegrationTests/Fake.DotNet.Cli.fs

Line 13 in 3f98e8d

[ testCase "Make sure dotnet installer works in paths with spaces - #2319"

install the latest version of the .NET SDK, which is a moving target (there is a lot of stuff going on in here)

[xperiandri]

I expect that workaround that I mentioned has to work

[Thorium]

#2783 could help this one as well.

[Numpsy]

When looking for info about problems with Mono.Posix.NetStandard on ARM macs, I found microsoft/sbom-tool#223 which suggests that they tried changing it to Mono.Unix to fix macOS ARM builds, but that broke it on Alpine Linux, so I'm not sure how good of an idea this would be if that's the case?
(there are also comments about that tool being fixed on .NET 8, but it looks like that's by removing the Mono.Posix dependency in that TFM rather that the .NET version fixing it directly)