[BUG] libSkiaSharp.so: undefined symbol: uuid_generate_random on Debian Bookworm ARM64

[HakanL]

Description

Using any version higher than 3.116.1 of SkiaSharp gives me the above error. I've tested with 3.118.* and 3.119, same error.

Code

using System;
using SkiaSharp;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Testing SkiaSharp...");
        using (var surface = SKSurface.Create(new SKImageInfo(100, 100)))
        {
            Console.WriteLine("SkiaSharp surface created successfully!");
        }
    }
}

Expected Behavior

"SkiaSharp surface created successfully!" should be written to the console

Actual Behavior

Error message: libSkiaSharp.so: undefined symbol: uuid_generate_random

Version of SkiaSharp

3.118.0-preview.2 (Next Preview)

Last Known Good Version of SkiaSharp

3.116.0 (Current)

IDE / Editor

Visual Studio (Windows)

Platform / Operating System

Linux

Platform / Operating System Version

Debian Bookworm

Devices

Raspberry Pi 4

Relevant Screenshots

No response

Relevant Log Output

Code of Conduct

• I agree to follow this project's Code of Conduct

[HakanL]

I tried to rebuild the Linux binaries for my distribution (Debian Bookworm on Arm64v8) and the build instructions were not 100%. Here's what I did, perhaps it helps somebody else with this issue:

Clone SkiaSharp and add submodules (I forgot this the first time)
git submodule init && git submodule update

Update debian docker file to .NET 9 and Debian 12 (Bookworm) (default is 10 and .NET 8, I assume the .NET version doesn't really matter, but I use 9 so I figured I may just as well, realizing it shouldn't matter when building the native binaries)

Build docker:
sudo docker build --tag skiasharp-debian -f scripts/Docker/debian/arm64v8/Dockerfile .

Run the docker image and build the native binaries:
sudo docker run --rm --name skiasharp-debian --volume $(pwd):/work skiasharp-debian /bin/bash build.sh --variant=debian --buildarch=arm64 --gn=/work/externals/depot_tools/gn --ninja=ninja --target=externals-linux --verifyglibcmax=2.36

Or if you want to run the build interactively for troubleshooting:
sudo docker run -it --rm --name skiasharp-debian --volume $(pwd):/work skiasharp-debian

Build command:
/bin/bash build.sh --variant=debian --buildarch=arm64 --gn=/work/externals/depot_tools/gn --ninja=ninja --target=externals-linux --verifyglibcmax=2.36

Rebuilding the native binaries and using those instead worked around the issue for me.

[nil4]

Similar issue with SkiaSharp 3.119.0 crashing at startup in an Avalonia app with the following output:

Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
symbol lookup error: /home/nil4/TestApp/bin/Debug/net9.0/runtimes/linux-arm64/native/libSkiaSharp.so: undefined symbol: uuid_parse

Initially reported at AvaloniaUI/Avalonia#18836 and triaged as:

AvaloniaUI/Avalonia#18836 (comment)

ARM version of libSkiaSharp.so doesn't list any dependencies while using symbols from libuuid. This likely means that -Wl,--no-undefined flag was missed from the build configuration. I'm also seeing FT_Get_BDF_Property symbol in the symbol table which suggests that the interned build of freetype is incomplete, so it will cause more convoluted native crashes when using font APIs later.

Please, file a bug at SkiaSharp repo, it's not an Avalonia issue.

[HakanL]

It's likely a duplicate of, or at least related to, #3229

[Riton2013]

I meet same problem, how to fix it ?

[rowan-gray]

Reposting this here. Originally posted in unoplatform/uno#20273.

---

The issue is caused by the arm64 libSkiaSharp.so binary not including DT_NEEDED entries for two required dependencies;

• libuuid.so.1 (defines uuid_generate_random)
• libfreetype.so.6 (defines FT_Get_BDF_Property)

You can check this by running ldd libSkiaSharp.so on the arm64 binary (must be run on an arm64 machine):

root@1e1c59122297:/app# ldd libSkiaSharp.so
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000005503080000)
        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x00000055030b0000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x00000055030e0000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000005503190000)
        /lib/ld-linux-aarch64.so.1 (0x0000005500000000)

The solution is to have these dependencies correctly added by SkiaSharp during the build.

In the meanwhile, you can patch the binary yourself as a workaround. Here's how you can do this on Ubuntu:

sudo apt-get update
sudo apt-get install patchelf

cd <pathToLibSkiaSharp.so>
patchelf --add-needed libuuid.so.1 libSkiaSharp.so
patchelf --add-needed libfreetype.so.6 libSkiaSharp.so 

# Confirm required dynamic dependencies are linked
ldd libSkiaSharp.so

This will need to be done on linux-aarch64. If you have an x86 machine instead of an arm machine, you can use qemu and docker to emulate an arm64 machine (this is what I did).

[rowan-gray]

@Riton2013 see the workaround above if you are still having this issue.

[kekekeks]

Please note that libSkiaSharp.so already contains its own private build of libfreetype. Attempting to resolve symbols from the system libfreetype can and will cause crashes once SkiaSharp version and system version will drift away enough with internal structures.