Arch Linux

Previous version's lddtree:

```
/usr/bin/neovide (interpreter => /lib64/ld-linux-x86-64.so.2)
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
libexpat.so.1 => /usr/lib/libexpat.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libz.so.1 => /usr/lib/libz.so.1
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
libpng16.so.16 => /usr/lib/libpng16.so.16
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0
libfreetype.so.6 => !!! circular loop !!!
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3
libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1
libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libm.so.6 => /usr/lib/libm.so.6
libc.so.6 => /usr/lib/libc.so.6
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
```

Patched:

```
/usr/bin/neovide (interpreter => /lib64/ld-linux-x86-64.so.2)
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0
libfreetype.so.6 => !!! circular loop !!!
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3
libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1
libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1
libpng16.so.16 => /usr/lib/libpng16.so.16
libz.so.1 => /usr/lib/libz.so.1
libexpat.so.1 => /usr/lib/libexpat.so.1
libjpeg.so.8 => /usr/lib/libjpeg.so.8
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libm.so.6 => /usr/lib/libm.so.6
libc.so.6 => /usr/lib/libc.so.6
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
```

Oops, seems the space indent didn't work.

So the only difference in the end result is libjpeg?

> FORCE_SKIA_BUILD won't work properly now

Why is this a problem when it's not currently used AFAICT? Sorry, but this report is not explained very well for idiots like me :P

Please also supply a proper patch for Arch instead of just "throwing over the wall" your custom build.

[1] Is not on any branch. Why not wait for a new release of rust-skia to include [2] then open a pull request to update to that release on upstream neovide?
Why was "options=(!lto)" added? Why the change to the sed substitution?

[1] https://github.com/rust-skia/rust-skia/commit/90f736d2cc76a2444e62c2773d7cf5524e6a59c2
[2] https://github.com/rust-skia/rust-skia/commit/f9005e2b603bc9e0e86de9bdc436bb2265cc18de

> So the only difference in the end result is libjpeg?

Former lddtree shows libpng16.so.16, libz.so.1 and libexpat.so.1 are linked from libfontconfig.so.1, not from the executable neovide.

> Why is this a problem when it's not currently used AFAICT?

First is that SKIA_USE_SYSTEM_LIBRARIES won't work properly and pulls libskia.a from rust-skia; using FORCE_SKIA_BUILD to force building Skia from source also won't work, as said above. I don't think we should rely on prebuilt binaries when building from source is an option.

> [1] Is not on any branch. Why not wait for a new release of rust-skia to include [2] then open a pull request to update to that release on upstream neovide?

[1] is on my fork. Also it seems that you are referring to my riscv64 build fix, which is not relevant to this bug report.

> Why was "options=(!lto)" added?

When LTO is on, linking to compiled Skia will fail; see attached build log.

> Why the change to the sed substitution?

Original sed substitution means turning off one of the default feature (binary-cache) on crate `skia-safe` (which in turn alters the features of `skia-bindings` of the same name); now with patches, feature binary-cache is needed to pull skia/third_party/external/ from Google, since there *are* dependencies that needs to be vendored. See description of https://github.com/rust-skia/rust-skia/pull/852.

Also `no-default-features = true` will not work; the correct way of disabling default features is `default-features = false`.

> Please also supply a proper patch for Arch instead of just "throwing over the wall" your custom build.
> Why not wait for a new release of rust-skia to include [2] then open a pull request to update to that release on upstream neovide?

This bug report is more of a POC/reminder to use as much system libraries (and in this case, system build tools like GN and Ninja) as possible. It takes time to make it work, for they are seldomly used in places other than Linux distros. (I might be wrong, so please point me out if I do)

I will submit a PR to rust-skia to include the system build tools patch. Once these PRs are all merged and released, we can switch to a lighter patch, only including new system libraries and environment variables for building. Or if using vendored build tools in depot_tools are fine, we can drop the GN and Ninja part.

>> [1] Is not on any branch. Why not wait for a new release of rust-skia to include [2] then open a pull request to update to that release on upstream neovide?
> [1] is on my fork. Also it seems that you are referring to my riscv64 build fix, which is not relevant to this bug report.
I was referring to line 36 of PKGBUILD.patch. [2] should have been [3] not [4] sorry for the confusion. As I was looking at the commit ordering on upstream rather than your fork which reversed the ordering of system library fix and the riscv64 fix I could not follow the commit choice.
>
> I will submit a PR to rust-skia to include the system build tools patch. Once these PRs are all merged and released, we can switch to a lighter patch,
Thank you.

[3] https://github.com/rust-skia/rust-skia/commit/328a4bd86cc340f1d8fd931b42dbc254dfa168a2
[4] https://github.com/rust-skia/rust-skia/commit/f9005e2b603bc9e0e86de9bdc436bb2265cc18de

Any status update here?