NixOS build broken

[quentinmit]

I think as a result of b36ab48 and/or 1e3e36a, the nix develop environment no longer functions:

$ ./Meta/ladybird.sh run ladybird
~/Software/ladybird/Toolchain/Tarballs ~/Software/ladybird/Toolchain
Preset CMake variables:

  CMAKE_BUILD_TYPE="RelWithDebInfo"
  CMAKE_TOOLCHAIN_FILE="/home/quentin/Software/ladybird/Toolchain/Tarballs/vcpkg/scripts/buildsystems/vcpkg.cmake"
  SERENITY_CACHE_DIR="/home/quentin/Software/ladybird/Build/caches"
  VCPKG_INSTALL_OPTIONS="--no-print-usage"
  VCPKG_OVERLAY_TRIPLETS="/home/quentin/Software/ladybird/Meta/CMake/vcpkg/release-triplets"

Preset environment variables:

  LADYBIRD_SOURCE_DIR="/home/quentin/Software/ladybird"
  VCPKG_BINARY_SOURCES="clear;files,/home/quentin/Software/ladybird/Toolchain/Build/vcpkg-binary-cache,readwrite"
  VCPKG_ROOT="/home/quentin/Software/ladybird/Toolchain/Tarballs/vcpkg"

-- Running vcpkg install
Could not start dynamically linked executable: /home/quentin/Software/ladybird/Toolchain/Tarballs/vcpkg/vcpkg
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld
-- Running vcpkg install - failed
CMake Error at Toolchain/Tarballs/vcpkg/scripts/buildsystems/vcpkg.cmake:899 (message):
  vcpkg install failed.  See logs for more information:
  /home/quentin/Software/ladybird/Build/ladybird/vcpkg-manifest-install.log
Call Stack (most recent call first):
  /nix/store/vnhl4zdy7igx9gd3q1d548vwzz15a9ma-cmake-3.27.7/share/cmake-3.27/Modules/CMakeDetermineSystem.cmake:148 (include)
  CMakeLists.txt:3 (project)


CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
-- Configuring incomplete, errors occurred!

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 in Ladybird/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.

[PaddiM8]

Getting the same on Asahi Fedora

[jesusmgg]

Also Alpine which uses musl instead of glibc. Can you confirm that your distros are also musl based?

This might be the same issue: #93

[PaddiM8]

@jesusmgg Nope, just regular Fedora for arm with some additions/tweaks (incl. 16 KiB pages).

[easrng]

I have fixes for this locally, I can PR

[easrng]

Fixing this properly is blocked on microsoft/vcpkg#39641 though

[quentinmit]

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:

• ladybird apparently requires icu 74 but NixOS currently ships icu 73 as default (74 is packaged as well, but somehow cmake is still finding 73 even if I put 74 in the shell)
• Skia doesn't have any packaging (NixOS has the 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.

[fgaz]

Fyi there are fixes for all of that here NixOS/nixpkgs#324050. I'm waiting for icu 7.4 to reach master, then I can update the downstream ladybird package.

edit: downstream tracking issue: NixOS/nixpkgs#325045

[socksy]

@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)

[MikMuellerDev]

Also broken for me (NixOS)
Currently waiting for the changes to propagate.

[ADKaster]

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

[philip-peterson]

I tried it and it worked for me. Ubuntu 14.04 LTS in UTM virtual machine.

[thomasqueirozb]

I got it to work merging changes from #738. Don't know how stable this is but it works

[ADKaster]

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:

1. Enter a nix shell with either nix-shell '' -A ladybird or using the experimental commands nix develop nixpkgs#ladybird.
2. 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
3. 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).