Skip to content
This repository has been archived by the owner on Feb 17, 2023. It is now read-only.

use dlib instead of static linking vendored copy #65

Closed
Be-ing opened this issue Feb 14, 2022 · 1 comment
Closed

use dlib instead of static linking vendored copy #65

Be-ing opened this issue Feb 14, 2022 · 1 comment

Comments

@Be-ing
Copy link

Be-ing commented Feb 14, 2022

I'm trying to cross compile my application from x86-64 Linux to aarch64-unknown-linux-gnu to build it for my Pinephone and I am stumbling over this crate. I tried using an ARM64 container to cross compile, but using emulation with QEMU requires 2 hours to build!

I'm using Slint which depends on this crate. This crate falls back to statically linking a vendored copy of libfontconfig if pkgconfig does not find it. This is problematic for two reasons. Most importantly, using a different copy of fontconfig than the system doesn't work as desired. Also, fontconfig requires a lot of C dependencies that need to be linked, which makes it difficult to get the vendored copy to build:

moire on  main [$!] is 📦 v0.1.0 via 🦀 v1.58.1
❯ pkg-config fontconfig --static --libs
-lfontconfig -lfreetype -lz -lbz2 -lpng16 -lm -lm -lz -lharfbuzz -lm -lglib-2.0 -lm -lpcre -lsysprof-capture-4 -pthread -lgraphite2 -lbrotlidec -lbrotlicommon -lxml2 -lz -llzma -lm

A solution to this would be using the dlib to let the user of the library either directly link fontconfig at build time or use dlopen to load it at runtime and remove the build time dependency. I recently helped implement this for the Rust JACK bindings and it makes cross compiling really easy. The Rust Wayland bindings use dlib as well and the X11 bindings have a similar option to use dlopen with the x11-dl crate.

This would also resolve #64.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant