- Status Closed
- Percent Complete
- 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
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
Sigh, if that would be the only problem..
hey , can u please edit the PKGBUILD because `wazi-compiler` is the main problem so please
can u please try to build with the latest wazi-compiler present in repo
See https://git.archlinux32.org/packages/commit/?id=173657e4057b9af336f032b304199ab094eaacd7
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..
So, this is a too old rust toolchain..
Latest rust is 1.61 (linked against llvm13), this can be forced, but then:
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).
wait so that means rust has no 32 bit?
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?
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..
Ok, doing a rust162 package built from rust 1.61, then I can build rust 1.63 with
rust162..
So, rust162 and rust 1.63 seem ok now. Rebuilding firefox 104.0.2 now..
Getting a link error after quite a while compiling:
So, at least icu needs a rebuild against new glibc 2.36…
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?
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..
This could also be a side effect of LTO linking, eliminating just the wrong
symbols..
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
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..
only i686 is a problem otherwise its okay , even for pentium4 i built vscode and more
Trying to rebuild cbindgen (firefox complains about it being to old), but
almost all cbindgen tests are failing:
Ah, they fail also on 64-bit, cool. :→
Ignoring failing tests, rebuilt cbindgen. Rebuilding firefox again now..
Back to square 1(-ish)..
isn't cross compiling possible , like u compile this 32 bit package in 64 bit?
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.
I'm trying to take out the gcc-10 patch, maybe this also causes the mismatches
in libstd++ with icu and some conditional variables..?
This is with gcc-10 removed (using gcc 12):
This is just a nightmare..
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….
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
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?
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…
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
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..
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..
i would again try this… i was compiling on an arch 64 bit machine…
again building…
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..
https://bugs.archlinux32.org/index.php?do=details&task_id=255&status%5B0%5D= seamonkey was failing in exactly the same way..
finally moving ahead … just waiting for another error…
on my x64 build i am not facing any problems in rust well for pentium4 will try to compile on a day or so
u were ultimately right about the style one even mine failed , i think rust 1.61 or ust 1.62
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
You can install llvm13-libs for libLLVM-13.so for falkon..
i think for firefox-esr lets try with rust-wasm
I'm now catching compiler intrinsics:
I have to check mozconfigs, there is no reason why we should get AVX2 here.
i am trying to compile falkon
Andreas , any errors? cuz my falkon build is going fine but that would take hours…
okay falkon for pentium4 is at 82%…
okay , falkon is also failing at 92%
No, falkon doesn't rebuild because of qt5-webengine is not rebuilding (there is
a separate bug report somewhere):
Now sadly also the llvm13-libs alone don't help, as we also have a stuck
ffmpeg:
And qt5-webengine is currently blocked in
https://bugs.archlinux32.org/index.php?do=details&task_id=282
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..
and
23:26.85 clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
So, we compile with rust,gcc and clang, nice:
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
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'
re: wasi:
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:
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)
given those changes above, the last few releases were compiling, until v105 today - it has some confusion about the machine class
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
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?
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?
Or it's part of this python-wathever mess called mach..
Or it's –enable-rust-simd on pentium4 enabling also AVX2, in this case staging-i686-build
should get over this compilation error..
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:
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
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)
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..
`falkon` is also failing to compile because of stdef.h on the cmake , anyways got suckless surf working! which just fullfills my needs
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..
i havent tried compiling v 105 for pentium4 so lemme set up a vm
let me try using @bill-auger 's things on the mozconfig
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
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
building firefox 104… on pentium4
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. :)
@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
my package for `firefox-esr` is going well , atleast for now
@bill-auger , for firefox 102 , wasi v13 is not required
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?
just to note, same problem with 105.0.2
void is on current firefox… they did not used any specific patch..
I wouldn't call that no patching:
https://github.com/void-linux/void-packages/tree/master/srcpkgs/firefox/patches
Still problems with 105.0.3:
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)..
Tons of:
This looks marginally worse..
29:39.61 ld.lld: error: failed to open libxul.so: Cannot allocate memory
Let's try with –threads=1..
nope:
29:38.48 ld.lld: error: failed to open libxul.so: Cannot allocate memory
the OOM problem is an old one, especially for libxul.so
i686 sets these flags set for that reason
i found a rather lengthy discussion about it - note comments #16 and #18 especially
https://bugzilla.redhat.com/show_bug.cgi?id=1658940#c16
that ticket suggests setting these flags:
however, the armv7h build does not set so many flags
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
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.
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).
Ah, thanks. The ticket might be helpful, I'll try to set more of those flags..
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..
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?
is it the same problem which made arch32 firefox stuck on 92 then 99?
Made a tentative AVX2 patch:
Now firefox builds up to:
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..
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).
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..
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)
Another way is to implement those atomic functions (AtomicOr32SeqCst, AtomicOr16SeqCst).. or maybe they are there somewhere and have to be
enabled..
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).
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.
Nice… pentium4 works for me… lets not close this ticket as long as firefox compiles non stop…
Yep, agreed, I also want to test the pentium4 and the i686 versions, especially because
of the AVX2 hack..
Yep, works. pushing to stable and marking as fixed.
The i686 version looks worse:
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
similar errors with LLVM, like:
https://termbin.com/2ujx
with these changes:
@@ -380,20 +384,22 @@ EOF
-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 –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
also, i forgot:
using the changes in my preceding message, i was able to compile 106.0.1 with –disable-webrtc
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
Thanks for the feedback, yes, I will try to build without webrtc and see if I
get a working i686 version..
builds fine. closing.