Arch Linux User Repository

@filips, seems to work indeed! It built fine on my side :)

I tried adding:

export CFLAGS="-fuse-linker-plugin"

to the build() function (before calling cargo build), and it seems to build and function correctly, even with LTO and ZSTD enabled. Can you please check if doing this (and re-enabling LTO and ZSTD) works for you?

diff --git a/PKGBUILD b/PKGBUILD
index faff4a9..dc92357 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -32,12 +32,11 @@ prepare() {

     # We don't use libexec on Arch
     sed -i "s@/usr/libexec/firefoxpwa-connector@/usr/lib/firefoxpwa/firefoxpwa-connector@g" manifests/linux.json
-
-    # Disable zstd feature (which currently makes the build fail on Arch)
-    sed -i "s/\"zstd\",//g" Cargo.toml
 }

 build() {
+    export CFLAGS="-fuse-linker-plugin"
+
     cd $srcdir/$_pkgname-$pkgver/native/
     RUSTUP_TOOLCHAIN=stable cargo build --release
 }

But I'm still not sure why this actually works. Because based on the zstd issue, GCC cannot be used for LTO with Rust, but adding this flag still worked appearently...

Well, but I would still like LTO to work :)

Appearently, this might be because CC is set to gcc instead of clang. So, maybe it's possible to detect when LTO is requested and set the correct CC and RUSTFLAGS to make it build properly. zstd crate also has fat-lto and thin-lto features, so maybe they also need to be set correctly, but I haven't tested this yet.

Also, I'm still curious why this happens only on Arch, and specifically with zstd crate, as other dependencies (even the ones that are also bindings to C libraries) seem to work fine without any additional configuration...

It seems Rust zstd crate sometimes has linking problems 0, often caused by LTO

Nice find! So you can actually just disable the LTO option in the PKGBUILD instead:

diff --git a/PKGBUILD b/PKGBUILD
index ace4fbe..01df0c9 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -18,6 +18,7 @@ license=("MPL2")

 makedepends=("rust" "cargo")
 optdepends=("firefox: Support for browser extension")
+options=('!lto')
 install=package.install

 source=("$pkgname-$pkgver.tar.gz::https://github.com/filips123/PWAsForFirefox/archive/refs/tags/v$pkgver.tar.gz")
@@ -33,9 +34,6 @@ prepare() {

     # We don't use libexec on Arch
     sed -i "s@/usr/libexec/firefoxpwa-connector@/usr/lib/firefoxpwa/firefoxpwa-connector@g" manifests/linux.json
-
-    # Disable zstd feature (which currently makes the build fails on Arch)
-    sed -i "s/\"zstd\",//g" Cargo.toml
 }

 build() {

Tested successfully on my side ;)

Thanks, I've added these lines to PKGBUILD in 2.12.0-2. It seems Rust zstd crate sometimes has linking problems (issues), often caused by LTO, but I don't know why it happens here specifically on Arch.

So, I'm not sure how to fix this properly. I will try to test it locally on Arch, but I probably won't have time soon.

Hi, thanks for the info!

Installing zstd didn't helped, so I added the following to the prepare() function in the PKGBUILD in the mean time:

    # Disable zstd feature (which currently makes the build fails on Arch)
    sed -i "s/\"zstd\",//g" Cargo.toml

It looks like zstd failed to link for some reason. It has been added as a dependency in 2.12.0 because I enabled zstd support for the HTTP client.

I don't know why it happens, as zstd-sys crate should statically link the vendored zstd library. It works fine for me locally (on Ubuntu) and on CI, so it appears to be an Arch-specific issue. Unfortunately, I currently can't test it on Arch...

You can try to install zstd libraries and build firefoxpwa again, maybe that will help link the library correctly. Or, you can also remove zstd feature from Cargo.toml (in line 42) to disable it.

Version 2.12.0-1 fails to build with:

          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)

error: could not compile `firefoxpwa` (bin "firefoxpwa") due to 1 previous error
==> ERROR: A failure occurred in build().
    Aborting...

Full build log: https://bpa.st/VWZA

ali.molaei, do firefoxpwa and firefoxpwa-connector themselves depend on dbus-glib, or does only Firefox runtime? Because I think these executables do not directly use any D-Bus functionalities, but Firefox does use D-Bus.

So, I'm not sure if it's appropriate to add D-Bus (and other Firefox-specific dependencies) to the firefox-pwa (and firefox-pwa-bin) package, because users might also use a different browser for runtime (like WaterFox, LibreWolf, etc.), which might have different dependencies. So, maybe adding them as optional dependencies would be better, but considering that Firefox is already listed as an optional dependency, I don't think that's really needed.

Looks like this package now needs dbus-glib