make gtk3Support non-optional, because it hasn't been for a long time
also make gtk2 conditional on firefox older than 90, because we can get
rid of it with firefox 90, but it's still needed by the current ESR
release
Since 37194a325d llvmPackages*.bintools is a bintools-wrapper. Thus it
only contains a wrapper for `as` and `ld`. This change makes sense, but
causes regressions like this one. Since the buildStdenv uses the llvm
bintool set including lld as a linker we can use the
cc.bintools.bintools derivation to get all the tools we need.
Technically we wouldn't need to set absolute paths as all tools are also
added to PATH, but it doesn't hurt either.
This will begin the process of breaking up the `useLLVM` monolith. That
is good in general, but I hope will be good for NetBSD and Darwin in
particular.
Co-authored-by: sterni <sternenseemann@systemli.org>
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Enable LTO support on Linux by default again.
Add patch to fix dependentlibs.list generation under LTO. This is
necessary for fixing firefox-wayland crashing when built with LTO.
Add makeFlags which set ar, ranlib, and nm to be llvm-ar, llvm-ranlib
and llvm-nm when building with llvm-based LTO. (bmo#1480005)
This was required to solve the XPCOMGlueLoad error when building with
LTO. However, it turns out libxul.so is supposed to have some libraries
that are reported as not found by ldd. Setting the RPATH worked around
the error as it forced dependency resolution but failed to fix the real
issue of broken generation of dependentlibs.list.
The libraries that are reported as not found by ldd are supposed to be
dlopened through the logic found in nsXPCOMGlue.cpp. However since the
generation of dependentlibs.list is broken under LTO this did not
happen. Instead of pulling libwayland-client.so from the GTK libraries
it found the stub library first (libmozwayland.so). The stub library
causes (as it should) wl_display_connect to always return NULL which is
the cause of the segmentation fault and LTO breaking wayland support.
Remove the hardcoded path used for the XPCOMGlueLoad error workaround
in NIX_LDFLAGS. libunwind is still unfortunately needed. Once the issue
of the generation of dependentlibs.list being borked is fixed it should
remedy the wayland crash issue on LTO.
Firefox has a number of optional dependencies that get dlopened.
Instead of using patchelf to set the RPATH use LD_LIBRARY_PATH.
The motivation for this is we already set LD_LIBRARY_PATH in the
wrapper on Linux.
It only affected FF80 so place an upper bound restriction. See
bmo#1661096 for details.
This fixes substituteStream() warnings about missing patterns which
appeared in the logs.
It was added for nspr and nss back in the 55.0.3 to 56.0 upgrade. It
also served as a workaround for an undeclared gio-unix-2.0 dependency.
Sometime afterwards nspr was removed, leaving just the two. Since then,
upstream has added a declaration for gio-unix-2.0 (in FF62). As for the
nss include it seemingly has no purpose since current firefox builds
with it removed.
After the fedora patches for screen sharing using pipewire got updated
for Firefox 83 (pipewire was inlined there), the nixpkgs buildInput
pipewire got stripped from the resulting firefox binary and so firefox
was unable to actually get the shared stream from the running pipewire
service.
Adding pipewire to the firefox binary with `patchelf --add-needed`
makes it atually get the stream from the service.
Fixes: #106812
libcubeb has dlopened libraries for awhile now. In nixpkgs there was
support for the PulseAudio backend doing this, however the ALSA backend
support was missed and caused issue #79310 (no sound with ALSA). This
gives ALSA users the ability to hear sound once again.
As discussed in #101429 firefox 82 started crashing when used with
wayland. A brief investigation showed that this appears to be rooted
within the LTO support that was recently added to the package. For the
time being, until someone figures out where the crashes are coming from,
we can just disable LTO.
This ensures that we aren't applying any of the experiemental pipewire
patches when the dependencies aren't enabled. As of now pipewire only
works with wayland and webrtc. If either of them are not activated we
can't build with pipewireSupport and we should not.
Martin Weinelt