SkiaSharp icon indicating copy to clipboard operation
SkiaSharp copied to clipboard

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

Open HakanL opened this issue 7 months ago • 8 comments

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

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

HakanL avatar May 09 '25 05:05 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.

HakanL avatar May 09 '25 16:05 HakanL

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 https://github.com/AvaloniaUI/Avalonia/issues/18836 and triaged as:

https://github.com/AvaloniaUI/Avalonia/issues/18836#issuecomment-2870938410

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.

nil4 avatar May 12 '25 07:05 nil4

It's likely a duplicate of, or at least related to, https://github.com/mono/SkiaSharp/issues/3229

HakanL avatar May 12 '25 13:05 HakanL

I meet same problem, how to fix it ?

Riton2013 avatar Aug 08 '25 07:08 Riton2013

Reposting this here. Originally posted in https://github.com/unoplatform/uno/issues/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 avatar Oct 14 '25 02:10 rowan-gray

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

rowan-gray avatar Oct 14 '25 02:10 rowan-gray

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.

kekekeks avatar Oct 29 '25 12:10 kekekeks

What would it take to push along fixes for this? SkiaSharp 3 is essentially broken on linux arm64 platforms due to this, which also means Avalonia 12 is completely broken on Arm64 platforms.

ThadHouse avatar Nov 25 '25 22:11 ThadHouse