Open quentinmit opened 4 months ago
Getting the same on Asahi Fedora
Also Alpine which uses musl instead of glibc. Can you confirm that your distros are also musl based?
This might be the same issue: https://github.com/LadybirdBrowser/ladybird/issues/93
@jesusmgg Nope, just regular Fedora for arm with some additions/tweaks (incl. 16 KiB pages).
I have fixes for this locally, I can PR
Fixing this properly is blocked on https://github.com/microsoft/vcpkg/issues/39641 though
NixOS is not musl-based. It just doesn't install libraries in /usr/lib
so pre-compiled binaries won't work.
I took a stab at trying to use native libraries instead of vcpkg
, but I ran into a couple problems:
skia-aseprite
fork packaged, but that's a couple years old and doesn't include CMake rules.)Both of these could probably be fixed with sufficient CMake-fu, but I don't want to go through the trouble and end up with something that upstream wouldn't merge.
Incidentally, the use of vcpkg
will probably also be a blocker for ladybird's inclusion in traditional distros like Debian too, since they have a strict policy of never using vendored dependencies.
Fyi there are fixes for all of that here https://github.com/NixOS/nixpkgs/pull/324050. I'm waiting for icu 7.4 to reach master, then I can update the downstream ladybird package.
edit: downstream tracking issue: https://github.com/NixOS/nixpkgs/issues/325045
@quentinmit fwiw I just packaged something else that uses skia and didn't really have any of the problems that this skia-asesprite had to work around. However as @fgaz points out in #382 skia is only available to be included via vcpkg, which while it's supported in NixOS, should not be used for actually fetching dependencies of packages (it's there to support dev environments afaict). As such #382 would be the real blocker for this issue.
(As an aside it's funny to me that the objections raised against allowing an escape hatch from vcpkg is that it would prevent reproducible builds, the raison d'être of the nix package manager in the first place)
Also broken for me (NixOS) Currently waiting for the changes to propagate.
If folks can verify that the nixpkgs build from ladybird-0-unstable-2024-07-11 works for them locally, we can close this issue with a documentation update explaining how to do that in BuildInstructionsLadybird.md
I tried it and it worked for me. Ubuntu 14.04 LTS in UTM virtual machine.
I got it to work merging changes from #738. Don't know how stable this is but it works
I think the last thing needed to resolve this is for a PR to remove the local nix env derivation, and update the nix build instructions documentation to do something like these steps to use the nixpkgs recipe as a baseline:
- Enter a nix shell with either nix-shell '
' -A ladybird or using the experimental commands nix develop nixpkgs#ladybird. - If this fix https://nixpk.gs/pr-tracker.html?pr=335702 did not reach your channel yet, run patchPhase to work around an issue with our libwebp
- Build normally with cmake
There are a few dependencies we've added since the latest nixpkgs update though, and we've removed a lot of our manual downloads. In theory it should be an even simpler .nix script today than it was two months ago (I hope).
I think as a result of b36ab480bf2c46ae9b327dc091d2e0813e3c8197 and/or 1e3e36af11bafd1f8a6fbdd4b5a6f9c93b3c8a07, the
nix develop
environment no longer functions:This appears to be because
BuildVcpkg.sh
is trying to download and run a pre-compiled executable, which doesn't work on NixOS. It needs to either use the vcpkg from nix (not currently part of the dependencies inLadybird/default.nix
), build vcpkg from source instead of installing a binary, or just use the Nix-provided versions of libraries instead of the vcpkg-provided ones.