[BUG] libSkiaSharp.so: undefined symbol: uuid_generate_random on Debian Bookworm ARM64
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
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.
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-undefinedflag was missed from the build configuration. I'm also seeingFT_Get_BDF_Propertysymbol 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.
It's likely a duplicate of, or at least related to, https://github.com/mono/SkiaSharp/issues/3229
I meet same problem, how to fix it ?
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).
@Riton2013 see the workaround above if you are still having this issue.
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.
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.