Arch Linux User Repository

Please refrain from abusing the flagging of a package as out of date for build issues. This is not what it is supposed to be used for.

I automatically get notified of comments to this package. I do not need to be notified of whatever build problems occur (whether they are an individual's problems or the actual package's problems) twice, and not via flagging it out of date.

Issues with this package can also be reported at https://codeberg.org/librewolf/issues/issues (as it is also maintained there, at https://codeberg.org/librewolf/arch, too).

@Hyolobrika: Hm, that's quite odd.

Would you care to give building it in a clean chroot a try (as outlined in https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot )? There might be something in your build environment / system that messes things up. Unfortunately, it's not really a "very helpful" error, so atm I can only give some very vague attempts at how to find out what's going on there / mitigate it – sorry about that!

@Cape

Remember that motion mark is a very specific test of browser performance. Which gets a bit more relevant once you look at canvas / canvas permissions as well as webgl/webgl2 etc. Some of those settings are restricted/changed in LibreWolf, so that's probably where you'd have to start looking at what's causing it – PGO/LTO shouldn't be the cause here.

To give you a starting point: There's an issue open that might be related at https://gitlab.com/librewolf-community/browser/windows/-/issues/54 – if you find something out (eg. which specific settings might trigger that kind of performance degradation in motion mark), it would be great if you could tell us! :)

Wow! So i built this package and performance in motion mark - compared to binary furryfox - is complete garbage!

furryfox score: 364 LibreWolf score: 35

I don't even care, but I'm curious to understand why? This is also a PGO+LTO optimized build, right? Maybe the profile run didn't work as expected? Is there something to look for?

Tried that separately and together. Neither worked.

diff --git a/PKGBUILD b/PKGBUILD
index 1b45a91..dc970c0 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -54,8 +54,14 @@ sha256sums_aarch64=('6ca87d2ac7dc48e6f595ca49ac8151936afced30d268a831c6a064b5203
 prepare() {
   mkdir -p mozbuild
   cd firefox-$pkgver
-
+  
+  # (Added by user) Try to limit resource usage to avoid errors per suggestion of lsf 
+  export LDFLAGS+=" -Wl,--no-keep-memory"
+  
   cat >../mozconfig <<END
+# (Added by user) Try to limit resource usage to avoid errors per suggestion of lsf
+mk_add_options MOZ_MAKE_FLAGS="-j1"
+
 ac_add_options --enable-application=browser
 mk_add_options MOZ_OBJDIR=${PWD@Q}/obj

That's quite possibly one of those "running out of resources / memory" errors.

You could try limiting the cores used (mk_add_options MOZ_MAKE_FLAGS="-j4" or even less) or trying to limit memory usage even more with export LDFLAGS+=" -Wl,--no-keep-memory".

Might be something else entirely – but in most cases of "somewhat vague build errors", it seems like it's been a resource issue.

Fails to build on Manjaro. rustc not working. Please help. 5e2c940f6dac

60:18.89 error: could not compile `gkrust`
60:18.90 Caused by:
60:18.90   process didn't exit successfully: `/usr/bin/rustc --crate-name gkrust toolkit/library/rust/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type staticlib --emit=dep-info,link -C opt-level=2 -C panic=abort -C embed-bitcode=no -Clto --cfg 'feature="cubeb-remoting"' --cfg 'feature="cubeb_pulse_rust"' --cfg 'feature="gecko_profiler"' --cfg 'feature="gecko_profiler_parse_elf"' --cfg 'feature="glean_disable_upload"' --cfg 'feature="glean_with_gecko"' --cfg 'feature="moz_memory"' --cfg 'feature="moz_places"' --cfg 'feature="oxidized_breakpad"' --cfg 'feature="quantum_render"' --cfg 'feature="remote_agent"' --cfg 'feature="simd-accel"' --cfg 'feature="webgpu"' --cfg 'feature="webrtc"' --cfg 'feature="with_dbus"' -C metadata=dce8fbbfa749f65b -C extra-filename=-dce8fbbfa749f65b --out-dir /home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C linker=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/build/cargo-linker -L dependency=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/release/deps --extern gkrust_shared=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/deps/libgkrust_shared-31902ab2f7c1522e.rlib --extern mozglue_static=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/deps/libmozglue_static-194fa8b790a693b1.rlib --extern mozilla_central_workspace_hack=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/deps/libmozilla_central_workspace_hack-35efc3fd5574a1fe.rlib --extern swgl=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/deps/libswgl-0f4d1c7c77605595.rlib -C opt-level=2 -C debuginfo=2 --cap-lints warn -Cembed-bitcode=yes -C panic=abort -C profile-generate=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj -C codegen-units=1 -L native=/usr/lib -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/build/audioipc-edd84eab446e6bfc/out -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/build/lmdb-rkv-sys-083790a362029eed/out -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/build/mozglue-static-d207304dbc98aca1/out -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/dist/bin -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/security/nss/lib/nss/nss_nss3 -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/security/nss/lib/ssl/ssl_ssl3 -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/config/external/nspr/pr -L native=/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/obj/x86_64-unknown-linux-gnu/release/build/swgl-fe846f4208cce657/out` (signal: 9, SIGKILL: kill)
60:18.92 make[4]: *** [/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/config/makefiles/rust.mk:356: force-cargo-library-build] Error 101
60:18.93 make[3]: *** [/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/config/recurse.mk:72: toolkit/library/rust/target] Error 2
60:18.94 make[2]: *** [/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/config/recurse.mk:34: compile] Error 2
60:18.94 make[1]: *** [/home/jacob/.cache/yay/librewolf/src/firefox-88.0.1/config/rules.mk:355: default] Error 2
60:18.95 make: *** [client.mk:65: build] Error 2
60:18.97 274 compiler warnings present.
==> ERROR: A failure occurred in build().
    Aborting...
error making: librewolf

Thanks !

Understood – I'll keep 'em ;)

(I honestly just didn't assume they were needed anymore in the future, but you make a good case – and as long as people are aware of the need to look out for .pacnew files, I see no harm in it :)

Hi @lsf, pelase do not remove:

backup=('usr/lib/librewolf/librewolf.cfg'
        'usr/lib/librewolf/distribution/policies.json')

See, it's not the same when you just want overwrite some values, which is what including ~/.librewolf/librewolf.overrides.cfg at the end of /usr/lib/librewolf/librewolf.cfg is meant for, than for commenting out some configs from /usr/lib/librewolf/librewolf.cfg, to get the FF default behavior instead.

For example to get safe browsing back, as it works on FF, the best is just comment out the librewolf configs, instead of specifying URLs, and several string values and the like.

I hope you don't remove those backup lines ever, :)

Thanks a lot !

Hm.. good point.

Never had this problem (with this package, at least), so I'd just naively assumed AUR helpers (like paru, in my case) checked for changes to checksums in the .SRCINFO and re-downloaded files accordingly.

To make all this less error prone, it would make sense to follow your hint, I guess, and do it the

"${pkgver}-${pkgrel}_patch_filename.patch::https://gitlab.com/whatever/patch_filename.patch"
# …
  patch -p1 -i ../${pkgver}-${pkgrel}_patch_filename.patch

way in the next release – thanks!

@lsf Caching sources is a makepkg feature. The names of the patches in this PKGBUILD are not unique and do not even depend on $pkgver, which causes these failures. See the warning in https://wiki.archlinux.org/index.php/PKGBUILD#source