• Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages → Packages: Build-list
  • Assigned To
    Andreas Baumann
  • Operating System pentium4
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Arch Linux 32
Opened by Pranjal - 13.08.2022
Last edited by Andreas Baumann - 31.10.2022

FS#281 - Firefox compilation

I checked the firefox on the build-list and its not compiling because of missing lvm13 libs which are packages are llvm13-libs and llvm13

Closed by  Andreas Baumann
31.10.2022 17:21
Reason for closing:  Fixed
Admin
Andreas Baumann commented on 14.08.2022 07:45

Sigh, if that would be the only problem.. ;-)

Average Linux Fan commented on 15.09.2022 03:34

hey , can u please edit the PKGBUILD because `wazi-compiler` is the main problem so please

  1. > wasi-compiler-rt=14.0.6-1.0
  2. > wasi-libc
  3. > wasi-libc++=14.0.6-1.0
  4. > wasi-libc++abi=14.0.6-1.0

can u please try to build with the latest wazi-compiler present in repo

Admin
Andreas Baumann commented on 15.09.2022 05:00

error: target not found: wasi-compiler-rt=14.0.6-1.0

Those dependencies are far too strict, they reference a specific Arch32 build version..
14.0.6 or >=14.0.0 should really be enough..

Admin
Andreas Baumann commented on 15.09.2022 05:06
 0:07.30 ERROR: cbindgen version 0.23.0 is too old. At least version 0.24.3 is required.
 0:07.30 Please update using 'cargo install cbindgen --force' or running
 0:07.30 './mach bootstrap', after removing the existing executable located at
 0:07.30 /usr/bin/cbindgen.
 Config object not found by mach.

So, this is a too old rust toolchain..

Admin
Andreas Baumann commented on 15.09.2022 05:14
error: process didn't exit successfully: `/usr/bin/rustc -vV` (exit status: 127)
--- stderr
/usr/bin/rustc: error while loading shared libraries: libLLVM-13.so: cannot open shared object file: No such file or directory

failed to run: /usr/bin/cargo build --manifest-path /build/rust/src/rustc-1.63.0-src/src/bootstrap/Cargo.toml --locked --frozen
Build completed unsuccessfully in 0:00:00

Latest rust is 1.61 (linked against llvm13), this can be forced, but then:

   Compiling core v0.0.0 (/build/rust/src/rustc-1.63.0-src/library/core)
error: attributes starting with `rustc` are reserved for use by the `rustc` compiler
  --> library/core/src/ffi/c_str.rs:80:3
   |
80 | #[rustc_has_incoherent_inherent_impls]
   |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: cannot find attribute `rustc_has_incoherent_inherent_impls` in this scope
  --> library/core/src/ffi/c_str.rs:80:3
   |
80 | #[rustc_has_incoherent_inherent_impls]
   |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0522]: definition of an unknown language item: `from_yeet`
   --> library/core/src/ops/try_trait.rs:340:1
    |
340 | #[lang = "from_yeet"]
    | ^^^^^^^^^^^^^^^^^^^^^ definition of unknown language item `from_yeet`

error[E0093]: unrecognized intrinsic function: `ptr_offset_from_unsigned`
    --> library/core/src/intrinsics.rs:1911:5
     |
1911 |     pub fn ptr_offset_from_unsigned<T>(ptr: *const T, base: *const T) -> usize;
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unrecognized intrinsic

error: unrecognized platform-specific intrinsic function: `simd_arith_offset`
  --> library/core/src/../../portable-simd/crates/core_simd/src/intrinsics.rs:65:5
   |
65 |     pub(crate) fn simd_arith_offset<T, U>(ptrs: T, offsets: U) -> T;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Some errors have detailed explanations: E0093, E0522.
For more information about an error, try `rustc --explain E0093`.
error: could not compile `core` due to 5 previous errors

Of course rust 1.63 cannot be built with rust 1.61, so we have to go through
bootstrapping through rust 1.62 binary version again (or build a 1.62 from
1.61 and 1.63 with 1.62, but usually this creates too many errors, so it's
easier to go binary - this also explains why there is no rust on 486 currently).

Average Linux Fan commented on 15.09.2022 07:36

wait so that means rust has no 32 bit?

Average Linux Fan commented on 15.09.2022 07:38

it seems quite weird that cbindgen is newer on i686 but its older on pentium4 , well give me some time i would try to compile it for pentium4 branch?

Admin
Andreas Baumann commented on 15.09.2022 09:16

There is Rust for IA32, at least for i686 and pentium4. It just got stuck in 1.61.
Firefox usually needs a rather new version to build.

This easily takes hours to build (both Rust and Firefox), so don't expect any fast
results. :-)

i686 and pentium4 can differ in SIMD support, so you're right, it seems odd: I
would also expect i686 to fail more and be older than pentium4..

Admin
Andreas Baumann commented on 15.09.2022 10:23

Ok, doing a rust162 package built from rust 1.61, then I can build rust 1.63 with
rust162..

Admin
Andreas Baumann commented on 15.09.2022 15:35

So, rust162 and rust 1.63 seem ok now. Rebuilding firefox 104.0.2 now..

Admin
Andreas Baumann commented on 15.09.2022 15:55

Getting a link error after quite a while compiling:

31:28.26 /usr/bin/ld.bfd: /usr/lib/libicuuc.so.71: undefined reference to `std::condition_variable::wait(
std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'
31:28.27 collect2: error: ld returned 1 exit status

So, at least icu needs a rebuild against new glibc 2.36…

Average Linux Fan commented on 15.09.2022 17:35

shall i make a package known as firefox-bin which downloads the firefox binary and installs it but it would be only for pentium4 so how do i do the i686 branch?

Admin
Andreas Baumann commented on 15.09.2022 18:13

You can use the one from the AUR:
https://aur.archlinux.org/packages/firefox-bin

same exists for thunderbird-bin, rust-bin, etc.
Being binary packages they might rise the CPU requirements to SSE2, so
it will be 'pentium4' subarchitecture only I'm afraid.

The bug above I have to fix anyway, then comes firefox again. But my poor
build machine can only build so much per day.. :-(

Admin
Andreas Baumann commented on 16.09.2022 07:04

This could also be a side effect of LTO linking, eliminating just the wrong
symbols..

Average Linux Fan commented on 16.09.2022 07:37

well , the firefox bin is only x86_64 so gotta edit its PKGBUILD and for me surf just works fine and got some x86_64 packages working on pentium4

Admin
Andreas Baumann commented on 16.09.2022 07:45

Yeah, changing architecture to 'pentium4' and change the download location to
https://archive.mozilla.org/pub/firefox/releases/104.0.2/linux-i686/… should
be fine..

Average Linux Fan commented on 16.09.2022 07:58

only i686 is a problem otherwise its okay , even for pentium4 i built vscode and more

Admin
Andreas Baumann commented on 16.09.2022 13:16

Trying to rebuild cbindgen (firefox complains about it being to old), but
almost all cbindgen tests are failing:

test test_assoc_const_conflict ... FAILED
test test_associated_constant_panic ... FAILED
test test_cdecl ... FAILED
test test_body ... FAILED
test test_cfg ... FAILED
test test_cfg_2 ... FAILED
Admin
Andreas Baumann commented on 16.09.2022 13:16

Ah, they fail also on 64-bit, cool. :→

Ignoring failing tests, rebuilt cbindgen. Rebuilding firefox again now..

Admin
Andreas Baumann commented on 16.09.2022 15:58
56:12.34 /usr/bin/ld.bfd: /usr/lib/libicuuc.so.71: undefined reference to `std::condition_variable::wait(
std::unique_lock<std::mutex>&)@GLIBCXX_3.4.30'

Back to square 1(-ish)..

Average Linux Fan commented on 17.09.2022 02:39

isn't cross compiling possible , like u compile this 32 bit package in 64 bit?

Admin
Andreas Baumann commented on 17.09.2022 05:43

Yeah, there is, but that's not what we do usually (but for bootstrapping a base
system for instance for i486). If normal compilation produces such headaches, the
headaches just increase when you cross-compile. :-)

Admin
Andreas Baumann commented on 17.09.2022 12:28
 0:02.44 DEBUG: _cc: Looking for gcc-10
 0:02.44 ERROR: Cannot find the target C compiler

I'm trying to take out the gcc-10 patch, maybe this also causes the mismatches
in libstd++ with icu and some conditional variables..?

Admin
Andreas Baumann commented on 17.09.2022 13:00

This is with gcc-10 removed (using gcc 12):

19:46.26 /usr/bin/ld.bfd: /build/firefox/src/firefox-104.0.2/obj/browser/app/../../memory/build/Unified_c
pp_memory_build0.o: TLS transition from R_386_TLS_LDM to R_386_TLS_LE_32 against `_ZL12thread_arena.0' at
 0x254 in section `.text._ZN7arena_t18RallocSmallOrLargeEPvjj' failed
19:46.26 /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value

This is just a nightmare..

Average Linux Fan commented on 18.09.2022 10:07

Even suckless surf is failing with a dri 2 error on arch32… well idk what to do here? qutebrowser , midori wont even load anything , otter worked but idk how to enable javascript there….

Average Linux Fan commented on 18.09.2022 10:53

0:21.15 checking for strerror… yes
0:21.45 checking for __cxa_demangle… yes
0:21.54 checking for unwind.h… yes
0:21.70 checking for _Unwind_Backtrace… yes
0:21.86 checking for _getc_nolock… no
0:22.01 checking for localeconv… yes
0:22.04 checking for nodejs… /usr/bin/node (18.9.0)
0:22.05 checking for gtk+-wayland-3.0 >= 3.14 xkbcommon >= 0.4.1 libdrm >= 2.4… yes
0:22.10 checking MOZ_WAYLAND_CFLAGS… -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 -pthread -I/usr/include/libdrm
0:22.10 checking MOZ_WAYLAND_LIBS… -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lxkbcommon -ldrm
0:22.11 checking for pango >= 1.22.0… yes
0:22.13 checking MOZ_PANGO_CFLAGS… -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/lzo -pthread -I/usr/include/pixman-1
0:22.13 checking MOZ_PANGO_LIBS… -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz
0:22.14 checking for fontconfig >= 2.7.0… yes
0:22.14 checking _FONTCONFIG_CFLAGS… -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -pthread
0:22.15 checking _FONTCONFIG_LIBS… -lfontconfig -lfreetype
0:22.16 checking for freetype2 >= 9.10.3… yes
0:22.17 checking _FT2_CFLAGS… -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -pthread
0:22.17 checking _FT2_LIBS… -lfreetype
0:22.18 checking for tar… /usr/bin/tar
0:22.18 checking for unzip… /usr/bin/unzip
0:22.19 checking for gn… not found
0:22.19 checking for the Mozilla API key… no
0:22.19 checking for the Google Location Service API key… no
0:22.19 checking for the Google Safebrowsing API key… no
0:22.19 checking for the Bing API key… no
0:22.19 checking for the Adjust SDK key… no
0:22.19 checking for the Leanplum SDK key… no
0:22.19 checking for the Pocket API key… no
0:22.20 checking for x11 xcb xcb-shm x11-xcb xext xrandr >= 1.4.0 xcomposite xcursor xdamage xfixes xi xtst… yes
0:22.21 checking MOZ_X11_CFLAGS… 0:22.22 checking MOZ_X11_LIBS… -lxcb-shm -lX11-xcb -lX11 -lxcb -lXext -lXrandr -lXcomposite -lXcursor -lXdamage -lXfixes -lXi -lXtst
0:22.23 checking for ice sm… yes
0:22.23 checking MOZ_X11_SM_CFLAGS… 0:22.25 checking for nasm… /usr/bin/nasm
0:22.27 checking nasm version… 2.15.05
0:22.27 ERROR: Cannot find a wasi sysroot. Please give its location with –with-wasi-sysroot. Or build with –without-wasm-sandboxed-libraries.
*** Fix above errors and then restart with "./mach build"

well , can u tell me how do i fix it , i am trying to compile firefox esr

Admin
Andreas Baumann commented on 18.09.2022 11:23

Old versions of DRI has been deprecated by mesa, not much I can do here. You can try mesa-amber
and see if it works better with old hardware.

The configure error comes from not having WASI tools installs (check PKGBUILD), or
add –without-wasm-sandboxed-libraries. Are you building firefox-esr from the Archlinux/Arch32 PKGBUILDs?

Average Linux Fan commented on 18.09.2022 12:08

No , i have a couple of pc's and most of them have arch except one having debian and i tried to compile from the original source to see it working and i am working on a archlinux based distro with runit or s6 which will have 32 bit so used this project…

Average Linux Fan commented on 18.09.2022 12:15

So gonna try without WASI stuff. I remember that firefox and chromium were frequently updated back in 2020 when these problems didnt occured and i had a p4 laptop which i used in 2020 and sold it but with arch32 only got a day to try…. it was a great experience so 99% of my older 32 bit pc's are using this

Admin
Andreas Baumann commented on 18.09.2022 12:24

Lemme build a firefox-esr, usually you have to either use the devtools32
(staging-pentium4-build) or you have to compile on real hardware (in order
not to have funny script probing things which then later are missing on
the machines you want to build for). firefox-esr is 102, so I would not be
astonished, if it has the same issues as newer versions..

Admin
Andreas Baumann commented on 18.09.2022 12:57
29:14.69 fatal runtime error: Rust cannot catch foreign exceptions
29:15.21 error: could not compile `style`
29:15.21 Caused by:
29:15.21   process didn't exit successfully: `/usr/bin/rustc --crate-name style --edition=2018 servo/components/style/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C embed-bitcode=no --cfg 'feature="bindgen"' --cfg 'feature="gecko"' --cfg 'feature="mozbuild"' --cfg 'feature="nsstring"' --cfg 'feature="regex"' --cfg 'feature="serde"' --cfg 'feature="toml"' -C metadata=8935190d5df9462b -C extra-filename=-8935190d5df9462b --out-dir /build/firefox-esr/src/firefox-102.2.0/obj/i686-unknown-linux-gnu/release/deps -:

they could at least probe for the rust version and then issue an error when
we use the wrong version. I'm not going to bisect this to find the matching
rust version to firefox-esr..

..and WASI has some many warnings I doubt somebody even tried to compile
that on 32-bit before..

..ok back to find the linker error, I suspect a LTS (local thread support)
mismatch somehow..

Average Linux Fan commented on 18.09.2022 13:43

i would again try this… i was compiling on an arch 64 bit machine…

Average Linux Fan commented on 18.09.2022 13:44

again building…

Admin
Andreas Baumann commented on 18.09.2022 13:47

Mmh, R_386_TLS_LDM to R_386_TLS_LE_32
R_386_TLS_LDM_32 to R_386_TLS_LE_32 would be more logical. I don't know
enough about thread local storage support yet..

Admin
Andreas Baumann commented on 18.09.2022 13:51
Average Linux Fan commented on 18.09.2022 13:57

finally moving ahead … just waiting for another error…

Average Linux Fan commented on 18.09.2022 14:11

on my x64 build i am not facing any problems in rust well for pentium4 will try to compile on a day or so

Average Linux Fan commented on 18.09.2022 14:25

u were ultimately right about the style one even mine failed , i think rust 1.61 or ust 1.62

Average Linux Fan commented on 19.09.2022 14:48

falkon is also failing for the same thing mentioned by Pranjal

[ 79%] Running generator for /build/falkon/src/falkon-22.08.1/src/plugins/PyFalkon/typesystem_pyfalkon.xml.
/usr/bin/
2: error while loading shared libraries: libLLVM-13.so: cannot open shared object file: No such file or directory

will try to compile for the pentium4 branch because my old atom netbook died 2 days ago in which i built some pentium4 packages

Admin
Andreas Baumann commented on 19.09.2022 15:08

You can install llvm13-libs for libLLVM-13.so for falkon..

Average Linux Fan commented on 19.09.2022 16:07

i think for firefox-esr lets try with rust-wasm

Admin
Andreas Baumann commented on 21.09.2022 07:07

I'm now catching compiler intrinsics:

 3:24.38 /build/firefox/src/firefox-105.0/mozglue/misc/SIMD_avx2.cpp:66:10: error: ‘_mm_cvtsi64_si128’ was not
 declared in this scope; did you mean ‘_mm_cvtsi32_si128’?
 3:24.38    66 |   return _mm_cvtsi64_si128(tmp);
 3:24.38       |          ^~~~~~~~~~~~~~~~~
 3:24.38       |          _mm_cvtsi32_si128

I have to check mozconfigs, there is no reason why we should get AVX2 here.

Average Linux Fan commented on 21.09.2022 09:23

i am trying to compile falkon

Average Linux Fan commented on 21.09.2022 10:15

Andreas , any errors? cuz my falkon build is going fine but that would take hours…

Average Linux Fan commented on 21.09.2022 11:33

okay falkon for pentium4 is at 82%…

Average Linux Fan commented on 21.09.2022 12:01

okay , falkon is also failing at 92%

Admin
Andreas Baumann commented on 21.09.2022 15:29

No, falkon doesn't rebuild because of qt5-webengine is not rebuilding (there is
a separate bug report somewhere):

/usr/bin/ld: warning: libavcodec.so.58, needed by /usr/lib/libQt5WebEngineCore.so.5.15.6, not found (try 
/usr/bin/ld: warning: libavformat.so.58, needed by /usr/lib/libQt5WebEngineCore.so.5.15.6, not found (try
/usr/bin/ld: warning: libavutil.so.56, needed by /usr/lib/libQt5WebEngineCore.so.5.15.6, not found (try u
/usr/bin/ld: /usr/lib/libQt5WebEngineCore.so.5.15.6: undefined reference to `av_packet_unref@LIBAVCODEC_5
/usr/bin/ld: /usr/lib/libQt5WebEngineCore.so.5.15.6: undefined reference to `avformat_alloc_context@LIBAV....

Now sadly also the llvm13-libs alone don't help, as we also have a stuck
ffmpeg:

falkon
falkon: error while loading shared libraries: libavcodec.so.58: cannot open shared object file: No such file or directory

And qt5-webengine is currently blocked in
https://bugs.archlinux32.org/index.php?do=details&task_id=282

Admin
Andreas Baumann commented on 21.09.2022 15:46

Tactics at the moment (and for some time) has been to create shim packages for
libs like boost, icu, llvm, (now also ffmpeg is probably needed?).

Keeping everything up to date gets harder and harder and with the shim package
at least you can run a recent version till the newer version is fixed..

Currently for too many things are simply broken..

Admin
Andreas Baumann commented on 22.09.2022 13:26
_ZN7arena_t18RallocSmallOrLargeEPvjj
arena_t::RallocSmallOrLarge(void*, unsigned int, unsigned int)

and

_ZL12thread_arena
thread_arena
Admin
Andreas Baumann commented on 22.09.2022 13:28

23:26.85 clang-14: error: linker command failed with exit code 1 (use -v to see invocation)

Admin
Andreas Baumann commented on 22.09.2022 13:50

So, we compile with rust,gcc and clang, nice:

 0:06.52 ERROR: Could not find clang to generate run bindings for C/C++. Please install the necessary packages, run `mach bootstrap`, or use --with-clang-path to give the location of clang.
bill-auger commented on 22.09.2022 13:52

i try to compile every release of firefox for i686 - most of the errors reported on this ticket, i have not seen - i will explains the ones i have seen

/usr/bin/rustc: error while loading shared libraries: libLLVM-13.so: cannot open shared object file: No such file or directory

that is the reason why llvm13 needs to be installed - note that llvm14 also needs to be installed

it also needs an override for 'python-pydantic'

# pydantic 1.10.2 has requirement typing-extensions>=4.1.0, but you have typing-extensions 3.10.0.0. - ('typing-extensions' is vendored; but 'python-pydantic' is not)
[[ "${CARCH}" == 'i686'   ]] && makedepends+=( python-pydantic=1.9.2 )

re: wasi:

ERROR: Cannot find a wasi sysroot. Please give its location with –with-wasi-sysroot. Or build with –without-wasm-sandboxed-libraries.

that is relatively new - IIRC i only needed to address that in v105 - or perhaps it was due to a recent change in the i686 system - anyways, to setup the wasi compiler:

ac_add_options --with-wasi-sysroot=/usr/share/wasi-sysroot

if wasi- v14 worked, then these overrides below would be needed - these are pinned to specific versions, only because v14 has not been working - since about v102, i have needed to use the wasi v13 toolchain, which is in the archive (the dustbin)

-makedepends=("${makedepends[@]/wasi-compiler-rt/wasi-compiler-rt=13.0.1-1.0}") # dustbin
+makedepends=("${makedepends[@]/wasi-compiler-rt/wasi-compiler-rt=14.0.6-1.0}") # dustbin
 makedepends=(${makedepends[*]/wasi-libc++*/})
-makedepends+=(wasi-libc++=13.0.1-1.0 wasi-libc++abi=13.0.1-1.0 llvm13) # dustbin
+makedepends+=(wasi-libc++=14.0.6-1.0 wasi-libc++abi=14.0.6-1.0 llvm13) # dustbin


given those changes above, the last few releases were compiling, until v105 today - it has some confusion about the machine class

mozglue/misc/SIMD_avx2.cpp:66:10: error: ‘_mm_cvtsi64_si128’ was not declared in this scope; did you mean ‘_mm_cvtsi64_si32’?

this is the code that is failing - it probably should not be hitting this code at all - as the note indicates, there is an analogous function in another file, named Load32BitsIntoXMM

#  if defined(__GNUC__) && !defined(__clang__)

// See the comment in SIMD.cpp over Load32BitsIntoXMM. This is just adapted
// from that workaround. Testing this, it also yields the correct instructions
// across all tested compilers.
__m128i Load64BitsIntoXMM(uintptr_t ptr) {
  int64_t tmp;
  memcpy(&tmp, reinterpret_cast<const void*>(ptr), sizeof(tmp));
  return _mm_cvtsi64_si128(tmp);
}

#  else

__m128i Load64BitsIntoXMM(uintptr_t ptr) {
  return _mm_loadu_si64(reinterpret_cast<const __m128i*>(ptr));
}

#  endif
Admin
Andreas Baumann commented on 23.09.2022 06:51

Ok, I think the rust thing applies to old stable, I rebuilt rust 1.63 should now be
in stable.

For WASI I read mixed results, maybe should deem it unstable and disable it?

SIMD_avx2.cpp:
#ifdef MOZILLA_MAY_SUPPORT_AVX2
...
#endif

./SSE.h:
#  define MOZILLA_MAY_SUPPORT_AVX2 1
#if defined(MOZILLA_PRESUME_AVX2)
#  define MOZILLA_MAY_SUPPORT_AVX2 1
...

#  ifdef __AVX2__
// It's ok to use AVX instructions based on the -march option.
#    define MOZILLA_PRESUME_AVX2 1

gcc -E -dM -x c /dev/null | grep -i avx2
returns no AVX2

So all this code should not be built actually.. let's add some #errors :-)

Maybe this part of the code is build with clang and has another idea about AVX2?

Admin
Andreas Baumann commented on 23.09.2022 06:56

Or it's part of this python-wathever mess called mach..

Admin
Andreas Baumann commented on 23.09.2022 07:01

Or it's –enable-rust-simd on pentium4 enabling also AVX2, in this case staging-i686-build
should get over this compilation error..

bill-auger commented on 23.09.2022 07:58

i think we can eliminate the –enable-rust-simd option as the cause; because i hit that error in mozglue/misc/SIMD_avx2.cpp with the i686 build - that has explicitly –disable-rust-simd

i think it is: "So all this code should not be built actually.."

the error i get with wasi-* 14 is this linking error:

wasm-ld: error: cannot open /usr/lib/clang/13.0.1/lib/wasi/libclang_rt.builtins-wasm32.a: No such file or directory
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

it is not happy with clang 13; but i tried clang 14, and that did not work either - IIRC, because some parts still expected clang 13 and/or llvm 13

bill-auger commented on 23.09.2022 08:05

icecat (firefox-esr) v102 compiled successfully for i686 today; so it is probably some difference in v105, which is causing the trouble

v102 does not require a downgrade of 'python-pydantic'; but v102 still required:
* llvm
* llvm13
* wasi-compiler-rt=13.0.1-1.0
* wasi-libc++=13.0.1-1.0
* wasi-libc++abi=13.0.1-1.0

i would focus on v104.0.1 for now - that was the last version, which i was able to compile successfully for i686

FWIW if arch32's firefox is usually ~5 releases behind arch, i would probably drop firefox in favor of the firefox-esr - it's release cycle is more of that pace - or alternatively, i will suggest again, that if arch32 users can live without DRM videos, you could simply take the parabola binaries of icecat and/or iceweasel instead - that would save you almost all of the workload, and provide arch32 users with an up-to-date firefox (at least whichever releases will compile without so much fuss)

Admin
Andreas Baumann commented on 23.09.2022 08:12

Thanks for all the feedback, bill-auger, much appreciated.. :-)

I can say now, that SSE.h has no effect on SIMD_avx2.cpp:

That one include a

#include "mozilla/SSE.h"

which I'm unable to find in the firefox sources..

Average Linux Fan commented on 23.09.2022 10:08

`falkon` is also failing to compile because of stdef.h on the cmake , anyways got suckless surf working! which just fullfills my needs

Admin
Andreas Baumann commented on 23.09.2022 13:09

falkon fails also because of pyside2, qt5-webengine and ffpmeg mixups, but those issue
don't belong here into the firefox compilation bug. :-)

I'll open new bugs instead..

Average Linux Fan commented on 24.09.2022 13:15

i havent tried compiling v 105 for pentium4 so lemme set up a vm

Average Linux Fan commented on 25.09.2022 05:58

let me try using @bill-auger 's things on the mozconfig

   # -fno-plt with cross-LTO -> LLVM ERROR: Function Import: link error
    CFLAGS="${CFLAGS/-fno-plt/}"
    CXXFLAGS="${CXXFLAGS/-fno-plt/}"
    # disable LTO (clang has issues on IA32)
    export RUSTFLAGS+=" -Cdebuginfo=0 -Clto=off"
    export LDFLAGS+=" -Wl,--no-keep-memory -Wl,--reduce-memory-overheads"
    # libvpx has some hard-coded compiler flags for MMX, SSE, SSE2, use the correct one
    # per CARCH (75.0 uses an intrisic _mm_empty now, which required the corresponding
    # architecture flag to be preset - before it was merely embedding some assembly
    # code with EMMS
    export CFLAGS+=" -mmmx"
    export CXXFLAGS+=" -mmmx"
bill-auger commented on 25.09.2022 08:30

just to note, none of those are "my things" - those are already in the arch32 build script, and have been for a long time

our routine for any packages which are in arch, which we need to re-build, is to firstly merge any changes from each of the upstream arches, and try to build it exactly as the upstream arch has configured it - i would diverge from the upstream arch configuration, only if necessary

it is almost never necessary though - firefox for i686 is a somewhat special case - i often build the latest release before arch32 does, and there usually are necessary changes for i686, which are not necessary for x86_64 or ARM, so those can not be merged from arch or archarm - so i need to troubleshoot and make those changes myself; and those changes are almost always necessary to build on arch32 also - so i tend to offer that (hard-earned) wisdom to arch32; to save them the trouble of hitting the same snags, and finding solutions to get past them

this time, my changes are only the wasi- bits, llvm13, and python-pydantic

bill-auger commented on 25.09.2022 08:36

just to cap that last statement, this time, i believe that firefox v105 has a regression affecting x86 with <SSE4 - i gave up trying to build it - life to short :) - if life were a bit longer, what we should do, is to report the bug to mozilla

my suggestion this time is forget v105 - build v104.0.1 instead; and wait for v106 to try again

Average Linux Fan commented on 25.09.2022 12:01

building firefox 104… on pentium4

Average Linux Fan commented on 25.09.2022 12:19

i have a long time to live for now… i am a 12 year old guy who loves arch linux and i have a lot of pc's now but the case was diffrent 2 years ago , i only had a pentium4 laptop and arch32 saved my life then i got a better hardware bu school forced to windows and this time withput caring for school came back to arch. :)

Average Linux Fan commented on 25.09.2022 13:37

@Andreas Baumann i found a way to compile style , its just a part of `webrender` which refuses to compile and a patch is there so i used it , just waiting

Average Linux Fan commented on 25.09.2022 14:09

my package for `firefox-esr` is going well , atleast for now

Average Linux Fan commented on 25.09.2022 14:15

@bill-auger , for firefox 102 , wasi v13 is not required

Admin
Andreas Baumann commented on 25.09.2022 16:18
52:06.16 /build/firefox/src/firefox-104.0.2/ipc/chromium/src/third_party/libevent/./arc4random.c:488:1: error: static declaration of 'arc4random_buf' follows non-static declaration
52:06.16 arc4random_buf(void *buf_, size_t n)
52:06.16 ^
52:06.16 /usr/include/stdlib.h:542:13: note: previous declaration is here
52:06.16 extern void arc4random_buf (void *__buf, size_t __size)
52:06.16             ^
52:06.24 1 error generated.
52:06.26 make[4]: *** [/build/firefox/src/firefox-104.0.2/config/rules.mk:590: Unified_c_src_third_party0.o] Error 1
52:06.26 make[3]: *** [/build/firefox/src/firefox-104.0.2/config/recurse.mk:72: ipc/chromium/src/third_party/target-objects] Error 2
52:06.26 make[3]: *** Waiting for unfinished jobs....

mmh firefox integrates chromium code, interesting.. :-)

arc4random_buf is a libbsd function, so is it now part of glibc?
So, this could be a new problem since glibc 2.36?

bill-auger commented on 07.10.2022 01:04

just to note, same problem with 105.0.2

mozglue/misc/SIMD_avx2.cpp:66:10: error: ‘_mm_cvtsi64_si128’ was not declared in this scope; did you mean ‘_mm_cvtsi64_si32’?
Average Linux Fan commented on 10.10.2022 18:28

void is on current firefox… they did not used any specific patch..

Admin
Andreas Baumann commented on 11.10.2022 04:24
Admin
Andreas Baumann commented on 11.10.2022 16:05

Still problems with 105.0.3:

36:09.37 /usr/bin/ld.bfd: /build/firefox/src/firefox-105.0.3/obj/browser/app/../../memory/build/Unified_cpp_memory_build0.o: TLS transition from R_386_TLS_LDM to R_386_TLS_LE_32 against `_ZL12thread_arena.0' at 0x254 in section `.text._ZN7arena_t18RallocSmallOrLargeEPvjj' failed
36:09.37 /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
Admin
Andreas Baumann commented on 12.10.2022 19:11

Ok, tentative trial to use the gold linker again, maybe its memory consumption got
better over time. Maybe just the bfd linker has problems knitting things together.
Default now seems to be the LLVM linker (which might be better, as Rust and clang
are used and most likely work best with lld)..

Admin
Andreas Baumann commented on 12.10.2022 19:29

Tons of:

18:42.39 /build/firefox/src/firefox-105.0.3/obj/dist/include/mozilla/ThreadLocal.h:181: error: missing expected TLS relocation
18:42.48 clang-14: error: linker command failed with exit code 1 (use -v to see invocation)

This looks marginally worse..

Admin
Andreas Baumann commented on 13.10.2022 05:09

29:39.61 ld.lld: error: failed to open libxul.so: Cannot allocate memory

Let's try with –threads=1..

Admin
Andreas Baumann commented on 13.10.2022 05:57

nope:

29:38.48 ld.lld: error: failed to open libxul.so: Cannot allocate memory

bill-auger commented on 13.10.2022 15:22

the OOM problem is an old one, especially for libxul.so

i686 sets these flags set for that reason

export RUSTFLAGS+=" -Cdebuginfo=0 -Clto=off"
> export LDFLAGS+=" -Wl,–no-keep-memory -Wl,–reduce-memory-overheads"

i found a rather lengthy discussion about it - note comments #16 and #18 especially

https://bugzilla.redhat.com/show_bug.cgi?id=1658940#c16

this is apparently a problem on all 32-bit arch's at this point.

that ticket suggests setting these flags:

"-Wl,–no-keep-memory -Wl,–no-keep-files-mapped -Wl,–no-map-whole-files -Wl,–no-mmap-output-file"
> "-Cdebuginfo=0 -Copt-level=0"

however, the armv7h build does not set so many flags

export LDFLAGS+=" -Wl,–no-keep-memory"
> export RUSTFLAGS="-Cdebuginfo=0"

but it sets a few others which i686 does not - the first one is essential for our arm build - with these options, i was able to compile iceweasel v105 for armv7h for the first time since v75

# increase codegen-units due to RAM constraints
> sed -i 's/codegen-units=1/codegen-units=16/' config/makefiles/rust.mk
echo 'ac_add_options –enable-optimize="-g0 -O2"' » .mozconfig
Admin
Andreas Baumann commented on 13.10.2022 15:34

No, even after 277:08.83 280 compiler warnings present.
277:08.71 ld.lld: error: failed to open libxul.so: Cannot allocate memory

with one thread.

So either we get linker stuff only ldd unterstands, or we can link presumably,
but ldd is not memory efficient, so it runs out of memory.

Admin
Andreas Baumann commented on 13.10.2022 15:44

Yes, I'll go through all local patching in:
https://git.archlinux32.org/packages/tree/extra/firefox/PKGBUILD

Some patches might no apply anymore (silently failing seds).

Admin
Andreas Baumann commented on 13.10.2022 15:45

Ah, thanks. The ticket might be helpful, I'll try to set more of those flags..

Admin
Andreas Baumann commented on 13.10.2022 18:13
export LDFLAGS+=" -Wl,–no-keep-memory -Wl,–reduce-memory-overheads"

This is for GNU ld, I don't see similar options to tame the memory hunger of lld.
And lld seems the only linker working..

Admin
Andreas Baumann commented on 21.10.2022 04:59

Tried 106.0 with all kind of linkers and flags.. Still running into strange
linker errors or out of memory. The only option left is to start cross-compiling
firefox maybe?

Average Linux Fan commented on 21.10.2022 15:34

is it the same problem which made arch32 firefox stuck on 92 then 99?

Admin
Andreas Baumann commented on 24.10.2022 18:16

Made a tentative AVX2 patch:

diff -rauN a/mozglue/misc/SIMD_avx2.cpp b/mozglue/misc/SIMD_avx2.cpp
--- a/mozglue/misc/SIMD_avx2.cpp        2022-10-24 18:34:51.028779452 +0200
+++ b/mozglue/misc/SIMD_avx2.cpp        2022-10-24 18:35:07.818868490 +0200
@@ -8,6 +8,7 @@
 #include "mozilla/SSE.h"
 #include "mozilla/Assertions.h"
 
+#undef MOZILLA_MAY_SUPPORT_AVX2
 #ifdef MOZILLA_MAY_SUPPORT_AVX2
 
 #  include <cstring>

Now firefox builds up to:

51:46.87 /build/firefox/src/firefox-106.0.1/modules/fdlibm/src/math_private.h:40:21: error: conflicting declaration ‘typedef __float_t float_t’
51:46.87    40 | typedef __float_t   float_t;
51:46.87       |                     ^~~~~~~
51:46.87 In file included from /usr/include/c++/12.2.0/cmath:45,
51:46.87                  from /build/firefox/src/firefox-106.0.1/obj/dist/system_wrappers/cmath:3,
51:46.87                  from /build/firefox/src/firefox-106.0.1/obj/dist/stl_wrappers/cmath:64,
51:46.87                  from /build/firefox/src/firefox-106.0.1/modules/fdlibm/src/e_acos.cpp:41:
51:46.87 /usr/include/math.h:169:21: note: previous declaration as ‘typedef long double float_t’
51:46.87   169 | typedef long double float_t;
51:46.87       |                     ^~~~~~~

This sounds familiar to the firefox-99.0.1-fdlibm-double.patch, but why
that one doesn't fail while patching, is not quite clear to me..

Admin
Andreas Baumann commented on 24.10.2022 18:17

The third issue is clang is being used, and that one only links with lld.
But we cannot use lld or gold (because of out-of-memory issues), so I
patched mozconfig to use gcc 12 (and bfd, plus some nice obscure linker
switches like .-Wl,–no-keep-memory -Wl,–reduce-memory-overheads -Wl,–max-cache-size=16384000. This at least got me over the out-of-memory-
issue to the float fdlibm issue..

I see land (on the horizon). :-)

Admin
Andreas Baumann commented on 24.10.2022 18:33

fdlibm is part of FreeMint (which I thought is a GEM-thingy!?). Why is this
part of firefox.. somebody wants to run GEM software in the browser..
this makes absolutely no sense to me.. :-)

Admin
Andreas Baumann commented on 25.10.2022 03:34
20:39.48 /build/firefox/src/firefox-106.0.1/js/src/jit/shared/AtomicOperations-shared-jit.cpp:88:9: error: ‘AtomicCopyByteUnsynchronized’ was not declared in this scope; did you mean ‘AtomicMemcpyUpUnsynchronized’?

So, if JIT compilation is not available on 32-bit, well, yes, I can switch it
off, but firefox will not be fast then.. (quite the contrary)

Admin
Andreas Baumann commented on 25.10.2022 03:35

Another way is to implement those atomic functions (AtomicOr32SeqCst, AtomicOr16SeqCst).. or maybe they are there somewhere and have to be
enabled..

Admin
Andreas Baumann commented on 25.10.2022 03:37

Just comparing to voidlinux: fix-i386-fdlibm.patch is the same FreeBSD patch for double_t. the float_t issue seems to be new (and might have to do with a newer
glibc in Archlinux than in Voidlinux).

Admin
Andreas Baumann commented on 25.10.2022 03:40

fix-i686-build-moz-1792159.patch from void sounds promising for the JIT issue..
..the fundamental philosophical problem with just getting patches from other
distros is: you loose the ability to fix those bugs yourself, and if everybody
copies from everybody else, nobody might be left to do anything.

Average Linux Fan commented on 25.10.2022 11:18

Nice… pentium4 works for me… lets not close this ticket as long as firefox compiles non stop…

Admin
Andreas Baumann commented on 25.10.2022 11:30

Yep, agreed, I also want to test the pentium4 and the i686 versions, especially because
of the AVX2 hack..

Admin
Andreas Baumann commented on 25.10.2022 14:03

Yep, works. pushing to stable and marking as fixed. :-)

Admin
Andreas Baumann commented on 30.10.2022 06:57

The i686 version looks worse:

29:25.18 /usr/lib/gcc/i686-pc-linux-gnu/12.2.0/include/xmmintrin.h: In member function ‘void webrtc::aec3
::VectorMath::Sqrt(rtc::ArrayView<float>)’:
...
29:25.19 /usr/lib/gcc/i686-pc-linux-gnu/12.2.0/include/xmmintrin.h:981:1: error: inlining failed in call to ‘always_inline’ ‘void _mm_storeu_ps(float*, __m128)’: target specific option mismatch
29:25.19   981 | _mm_storeu_ps (float *__P, __m128 __A)
29:25.19       | ^~~~~~~~~~~~~
29:25.19 /build/firefox/src/firefox-106.0.1/third_party/libwebrtc/modules/audio_processing/aec3/vector_math.h:55:24: note: called from here
29:25.19    55 |           _mm_storeu_ps(&x[j], g);
29:25.19       |           ~~~~~~~~~~~~~^~~~~~~~~~
bill-auger commented on 30.10.2022 21:06

same on parabola

/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:981:1: error: inlining failed in call to ‘always_inline’ ‘void _mm_storeu_ps(float*, m128)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:208:1: error: inlining failed in call to ‘always_inline’ ‘
m128 _mm_sqrt_ps(m128)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:932:1: error: inlining failed in call to ‘always_inline’ ‘
m128 _mm_loadu_ps(const float*)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:981:1: error: inlining failed in call to ‘always_inline’ ‘void _mm_storeu_ps(float*, m128)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:208:1: error: inlining failed in call to ‘always_inline’ ‘
m128 _mm_sqrt_ps(m128)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:932:1: error: inlining failed in call to ‘always_inline’ ‘
m128 _mm_loadu_ps(const float*)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:208:1: error: inlining failed in call to ‘always_inline’ ‘m128 _mm_sqrt_ps(m128)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:932:1: error: inlining failed in call to ‘always_inline’ ‘m128 _mm_loadu_ps(const float*)’: target specific option mismatch
/usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:981:1: error: inlining failed in call to ‘always_inline’ ‘void _mm_storeu_ps(float*,
m128)’: target specific option mismatch

bill-auger commented on 31.10.2022 03:39

similar errors with LLVM, like:

/build/iceweasel/src/firefox-106.0.1/third_party/libwebrtc/modules/audio_processing/aec3/adaptive_fir_filter.cc:110:27: error: always_inline function '_mm_loadu_ps' requires target feature 'sse', but would be inlined into function 'ComputeFrequencyResponse_Sse2' that is compiled without support for 'sse'
> ….
> fatal error: too many errors emitted, stopping now [-ferror-limit=]

https://termbin.com/2ujx

with these changes:

@@ -380,20 +384,22 @@ EOF

   # disable SIMD (SSE2 for i686)
   # set correct compiler and toochain tools
   cat >>../mozconfig <<END

-ac_add_options –disable-linker=lld
-ac_add_options –enable-linker=bfd
+#ac_add_options –disable-linker=lld
+#ac_add_options –enable-linker=bfd
ac_add_options –disable-lto
ac_add_options –disable-rust-simd

ac_add_options --enable-strip

ac_add_options –disable-debug
ac_add_options –disable-debug-symbols
-export CC=gcc
-export CXX=g++
-export AR=gcc-ar
-export NM=gcc-nm
-export RANLIB=gcc-ranlib
+#export CC=gcc
+#export CXX=g++
+#export AR=gcc-ar
+#export NM=gcc-nm
+#export RANLIB=gcc-ranlib
export STRIP=strip
END

bill-auger commented on 31.10.2022 10:09

also, i forgot:

-    export LDFLAGS+=" -Wl,--no-keep-memory -Wl,--reduce-memory-overheads"
+    export LDFLAGS+=" -Wl,--no-keep-memory -Wl,--reduce-memory-overheads"  # with GCC
+    export LDFLAGS+=" -Wl,--no-keep-memory "                               # without GCC

using the changes in my preceding message, i was able to compile 106.0.1 with –disable-webrtc

+    # FIXME GCC: /usr/lib/gcc/i686-pc-linux-gnu/12.1.0/include/xmmintrin.h:208:1: error: inlining failed in call to ‘always_inline’ ‘__m128 _mm_sqrt_ps(__m128)’: target specific option mismatch
+    # FIXME LLVM: /build/iceweasel/src/firefox-106.0.1/third_party/libwebrtc/modules/audio_processing/aec3/adaptive_fir_filter.cc:110:27: error: always_inline function '_mm_loadu_ps' requires target feature 'sse', but would be inlined into function 'ComputeFrequencyResponse_Sse2' that is compiled without support for 'sse'
+    echo "ac_add_options --disable-webrtc" >> ../mozconfig

the browser runs well - i did not try webrtc - i did not try with GCC

if the existing the arch32 firefox webrtc does not work well, or if webrtc support is acceptable loss, maybe this would be an improvement over-all

Admin
Andreas Baumann commented on 31.10.2022 16:05

Thanks for the feedback, yes, I will try to build without webrtc and see if I
get a working i686 version..

Admin
Andreas Baumann commented on 31.10.2022 17:21

builds fine. closing.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing