Because of long standing bugs and stability issues & an
uncollaborative upstream there has been talk on the emacs-devel
mailing list to switch the default toolkit to
Lucid (https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00752.html).
The GTK build also has issues with Xinput2, something that both we and
upstream want to enable by default in Emacs 29.
This situation has prompted me to use both Lucid an no-toolkit (pure X11) Emacs
as a daily driver in recent weeks to evaluate what the
advantages/drawbacks are and I have concluded that, at least for me,
switching the toolkit to Lucid is strictly an upgrade.
It has resulted in better stability (there are far fewer tiny UX
issues that are hard to understand/identify) & a snappier UI.
On top of that the closure size is reduced by ~10%.
In the pure X11 build I noticed some unsharpness around fonts so this
is not a good default choice.
As with everything there is a cost, and that is uglier (I think most
would agree but of course this is subjective) menu bars for
those that use them and no GTK scroll bars.
For anyone who still wants to use GTK they could of course still
choose to do so via the new `emacs-gtk` attribute but I think this
is a bad default.
A note to Wayland users:
This does not affect Wayland compatibility in any way since that will
already need a PGTK build variant in the future.
The build was failing with the following error:
```
[18950/51180] SOLINK ./libvk_swiftshader.sotls_transport_interface/dtls_transport_interface.omputils.o[K.otch.oos.oKx/unbundle:default)fault)ault)
FAILED: libvk_swiftshader.so libvk_swiftshader.so.TOC
python3 "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libvk_swiftshader.so" --tocfile="./libvk_swiftshader.so.TOC" --output="./libvk_swiftshader.so" -- clang++ -shared -Wl,-soname="libvk_swiftshader.so" -Wl,-Bsymbolic -Wl,--version-script=../../third_party/swiftshader/src/Vulkan/vk_swiftshader.lds -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=all -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10\%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=30 -fwhole-program-vtables -Wl,--no-call-graph-profile-sort -m64 -no-canonical-prefixes -Wl,-O2 -Wl,--gc-sections -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -Wl,--lto-O0 -fsanitize=cfi-vcall -fsanitize=cfi-icall -o "./libvk_swiftshader.so" @"./libvk_swiftshader.so.rsp"
ld.lld: error: unable to find library -l:libffi_pic.a
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
This turned out to be a regression from b6b51374fc. That change was
bad/undesirable in the first place and I only applied it to quickly fix
another build error caused by incompatible wayland-protocols header
files from a newer system version (Chromium bundles version 1.21 while
we already package 1.26).
The better fix for that wayland-protocols build issue is to pull in a
patch that is already used/tested by the Arch package [0] and seems to
originate from [1] (not sure if that patch was formally submitted yet).
Alternatives to that patch would be to (we should probably first try the
first approach if need be):
1) Build with wayland-protocols 1.21 from the system (by overriding the
Nixpkgs package).
2) Dynamically link against libffi by patching [2] to use the other
branch (`default_toolchain == "//build/toolchain/cros:target"`).
Some additional details can be found in the GitHub PR [3].
Huge thanks to Lorenz Brun for his great analysis that enabled me to fix
the build so that we can finally merge the update to Chromium M105
(which contains many important security fixes!).
[0]: a353833a5a
[1]: https://bugs.chromium.org/p/angleproject/issues/detail?id=7582#c1
[2]: https://source.chromium.org/chromium/chromium/src/+/refs/tags/105.0.5195.52:build/config/linux/libffi/BUILD.gn
[3]: https://github.com/NixOS/nixpkgs/pull/189033
Co-Authored-By: Lorenz Brun <lorenz@brun.one>
