Properly Detect & Handle Musl Systems #1657

mattleibow · 2021-03-13T09:38:48Z

Description of Change

When running under mono/net4x, the musl libraries were copied over the glibc libraries, meaning that nothing worked.

This PR not only stops doing that and copies the musl libraries into a sub-folder, but also does runtime detection of Musl and then picks those ones.

Bugs Fixed

Fixes [BUG] musl binaries overwrite ones built for the normal glibc #1637

API Changes

Behavioral Changes

PR Checklist

Has tests (if omitted, state reason in description)
Rebased on top of main at time of PR
Changes adhere to coding standard
Updated documentation

Fixes #1637

mattleibow · 2021-03-13T09:42:19Z

binding/Binding.Shared/LibraryLoader.cs

+					if (PlatformConfiguration.IsMusl) {
+						var muslLib = Path.Combine (root, "musl-" + arch, libWithExt);
+						if (File.Exists (muslLib)) {
+							foundPath = muslLib;
+							return true;
+						}
+					}


If a Musl system, first check the musl-* directories.

mattleibow · 2021-03-13T09:43:15Z

binding/Binding.Shared/PlatformConfiguration.cs

+				switch (cpu)
+				{
+					case Architecture.X86:
+						return AccessCheck("/lib/libc.musl-x86.so.1", 0) == 0;


Checking for /lib/libc.musl-* seems to be a decent way to detect Musl systems. If all else fails, then we fallback to the existing logic.

The existence of that file does not indicate the libc variant that's used by the current process.

😢 Is there any way to check for Musl? Is there some specific thing that exists in Musl or glibc that we can use to detect? Maybe there is some thing we call that returns a string that says musl or not?

What if I told you that technically one system can have both?

I guess you could try to DllImport gnu_get_libc_version from libc and see if it throws
EntryPointNotFoundException. If it doesn't, you are definitely running with glibc.

BTW, since that check happens at runtime, I'd suggest to expose an API for selecting the proper binary and some SkiaSharp-specific environment variable (e. g. SKIASHARP_LIBC_FLAVOR). So detection logic would look like this:

use API-provided-override if configured

use the value from environment variable if exists

attempt to auto-detect

Good point. Let me add that.

I only added 1. as I don't want a library to be reaching out into the environment. This can of course be added by a consuming library or by the final app. However, the API that I am making public is the existing PlatformConfiguration class. This was previously used just to detect the OS, arch or pointer size, however, I added both a IsMusl and IsMuslOverride which can be used to control if the process is glibc or musl:

// use default fallback PlatformConfiguration.IsMuslOverride = null; // is Musl PlatformConfiguration.IsMuslOverride = true; // is NOT Musl PlatformConfiguration.IsMuslOverride = false;

If there is ever another libc, we can just add a new IsXlibc and a IsXlibcOverride. Then it still up to the consumer to set the correct values. The recommendation is to only set when you are sure it is one or the other. Although not very high chance we will get another libc, setting it to false when unsure will make the detection checks stop early.

If SkiaSharp is detecting Musl incorrectly, then it should be seen as a bug and hopefully will get reported and fixed so the override should remain mostly unused.

Actually, I am making the API internal for now and can be accessed via reflection. I have tests to make sure it stays.

The reason for this is that this lookup system only exists on mono and we are really starting to move away from that. I added the API for the existing apps that need to control the lookup, but with .NET Core and .NET 5+, all the lookup is done via the runtime features.

And if there is some pluggable system that needs multiple versions of libSkiaSharp in memory, then this is still not an issue because since .NET Core 3.0 there is the NativeLibrary which is the preferred and more correct way to override the loading mechanism: https://docs.microsoft.com/dotnet/api/system.runtime.interopservices.nativelibrary

Well, it should actually be using the AssemblyLoadContext and works with the results of a Publish for a project. I created a sample with SkiaSharp based on the docs: https://github.com/mattleibow/SkiaSharpPluggable

binding/SkiaSharp/nuget/build/net462/SkiaSharp.targets

kekekeks · 2021-03-20T20:03:59Z

binding/Binding.Shared/PlatformConfiguration.cs

@@ -50,18 +50,20 @@ static PlatformConfiguration ()
 			Is64Bit = IntPtr.Size == 8;
 		}

+		public static bool? IsMuslOverride { get; set; }


Technically there are other libc implementations, so I'd suggest to have something like

enum LibcFlavor { Glibc, Musl }

OK, so I changed the whole way of selecting a variant/flavor.

There is now a property LinuxFlavor that can be used to control the whole thing instead of the specific IsMusl. This is useful in cases where there needs to be a specific version of Linux. For example if you need a custom build for say FreeBSD. You can set the flavor at app startup following any checks that you do and then the lookup will use that first.

If the property is null, then I just do the basic glibc/musl check - or rather I check for glibc and assume musl otherwise. If a specific flavor is set, then I do nothing and just use that. This is just a plain string that allows for extension later on, and also is just the name of the folder to use.

Example usage would be on a x64 machine:

LinuxFlavor == null with glibc => 'x64'

LinuxFlavor == null with non-glibc => 'musl-x64'

LinuxFlavor == freebsd => 'freebsd-x64'

Since this is totally customizable, you can even do specific checks for versions and set the flavor to opensuse.14 and then it will look in opensuse.14-arm64 if it were running on an ARM64 machine.

kekekeks · 2021-07-07T10:07:11Z

binding/Binding.Shared/LibraryLoader.cs

@@ -192,7 +191,7 @@ private static class Mac

 		private static class Linux
 		{
-			private const string SystemLibrary = "libdl.so";
+			private const string SystemLibrary = "dl";


@mattleibow apparently this throws DllNotFoundException on a somewhat clean Ubuntu 20.04 installation

Properly Musl systems

3037ecc

Fixes #1637

mattleibow added this to In progress in v2.80.3 via automation Mar 13, 2021

mattleibow changed the title ~~Properly Musl systems~~ Properly Detect & Handle Musl Systems Mar 13, 2021

mattleibow mentioned this pull request Mar 13, 2021

[BUG] musl binaries overwrite ones built for the normal glibc #1637

Closed

mattleibow added 2 commits March 13, 2021 11:44

lazier

b0b7596

lazier-er

4364a3f

mattleibow commented Mar 13, 2021

View reviewed changes

mattleibow added 7 commits March 13, 2021 15:03

take 4

08810d1

take 5

8b6e573

Merge branch 'main' into dev/musl

d5ecc56

Use a better check for glibc

624fb2a

Make PlatformConfiguration public

c6c31ea

Make internal for now

ed541a3

:|

164a7f5

kekekeks reviewed Mar 20, 2021

View reviewed changes

mattleibow added 6 commits March 21, 2021 15:21

oops

9506288

Allow total override of the linux flavor

d068e57

reflection is hard

c9ccdf1

Merge branch 'main' into dev/musl

2df2e5a

Merge branch 'main' into dev/musl

6ccc082

this is static and might be in use by the OS

c34ba02

mattleibow merged commit 8b44e79 into main May 20, 2021

v2.80.3 automation moved this from In progress to Done May 20, 2021

mattleibow deleted the dev/musl branch May 20, 2021 07:09

kekekeks reviewed Jul 7, 2021

View reviewed changes

mattleibow mentioned this pull request Nov 5, 2021

Add the initial point for internal library configuration #1856

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Properly Detect & Handle Musl Systems #1657

Properly Detect & Handle Musl Systems #1657

mattleibow commented Mar 13, 2021

mattleibow Mar 13, 2021

mattleibow Mar 13, 2021

kekekeks Mar 13, 2021

mattleibow Mar 19, 2021

kekekeks Mar 19, 2021

kekekeks Mar 19, 2021

kekekeks Mar 20, 2021 •

edited

Loading

mattleibow Mar 20, 2021

mattleibow Mar 20, 2021

mattleibow Mar 20, 2021

mattleibow Mar 20, 2021

kekekeks Mar 20, 2021

mattleibow Mar 21, 2021 •

edited

Loading

kekekeks Jul 7, 2021

Properly Detect & Handle Musl Systems #1657

Properly Detect & Handle Musl Systems #1657

Conversation

mattleibow commented Mar 13, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kekekeks Mar 20, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattleibow Mar 21, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kekekeks Mar 20, 2021 •

edited

Loading

mattleibow Mar 21, 2021 •

edited

Loading