fix: allow dlopen on statically-linked musl binaries

The isDynamicBinary() check prevents loadLibrary from attempting dlopen
on statically-linked Linux binaries. This is correct for glibc, where
dlopen from static binaries is undefined behavior and can crash, but
overly conservative for musl libc, which has a fully functional dlopen
implementation even in static binaries.

Add an isMusl() check so that static binaries on musl-based systems
(like Alpine Linux) can still load native libwebp via dlopen. On glibc
systems the existing guard is preserved.

This enables native libwebp loading in Alpine/Docker environments where
Go+CGO+musl produces static binaries by default.

Author: deluan

purego_unix.go

@@ -7,6 +7,7 @@ import (
 	"fmt"
 	"os"
 	"runtime"
+	"strings"
 
 	"github.com/ebitengine/purego"
 )
@@ -17,7 +18,7 @@ const (
 )
 
 func loadLibrary(name string) (uintptr, error) {
-	if runtime.GOOS == "linux" && !isDynamicBinary() {
+	if runtime.GOOS == "linux" && !isDynamicBinary() && !isMusl() {
 		return 0, fmt.Errorf("not a dynamic binary")
 	}
 
@@ -49,3 +50,28 @@ func isDynamicBinary() bool {
 
 	return false
 }
+
+// isMusl returns true if the current process is linked against musl libc.
+// Musl supports dlopen from statically-linked binaries, unlike glibc.
+func isMusl() bool {
+	maps, err := os.ReadFile("/proc/self/maps")
+	if err == nil && strings.Contains(string(maps), "musl") {
+		return true
+	}
+
+	// For static binaries /proc/self/maps won't show musl.
+	// Check if the musl dynamic linker exists on the system.
+	for _, path := range []string{
+		"/lib/ld-musl-aarch64.so.1",
+		"/lib/ld-musl-x86_64.so.1",
+		"/lib/ld-musl-armhf.so.1",
+		"/lib/ld-musl-i386.so.1",
+		"/lib/ld-musl-riscv64.so.1",
+	} {
+		if _, err := os.Stat(path); err == nil {
+			return true
+		}
+	}
+
+	return false
+}