Pale Moon for Raspberry Pi (and friends) Topic is solved

[haggster]

Hi! I don't know if you're still following this thread, but I just wanted to say that I'm using your build on my ARM Chromebook via crouton now and everything was working flawlessly. I used the automatic installation script. From what I remember when I was using Firefox on the same machine, I have to say that your Palemoon build is leagues above that, performance-wise.

It's Pale Moon 26.1.1 BTW.

Looking forward to new versions in case you get to compile some (but I know how annoying that can be... I've once contributed a VeraCrypt armv7 build (built on this same Chromebook) and so far I've never managed to provide an updated build - and that was 2yrs ago now ).

Anyway, happy to have this! Kudos!

[haggster]

dimag0g: in case you're still around - from what you wrote, you were not cross compiling this, but you built this directly on the armv7 target architecture, right? I assume you were using an external HDD with sufficient space to compile the whole thing?

Anyway, I was just wondering whether it'd be possible that you could attach the .mozconfig which you were using here and maybe provide the steps required for successfully compiling this on ARM. I've seen the Github repo, but I assume that there are some other details that are necessary to compile this. If the instructions are available, everyone could compile their own version and we could make sure that we have more recent releases available. I think one of the most important aspects would be to have "HTML5 video" support, since I've e.g. tried out both, gnash and lightspark, and also mozilla's flash-conversion (forgot the name) addon, but none are able to play any youtube videos. So getting those codecs to run should be a priority.

If anyone else is interested in getting working armv7 builds, then just let me know. I've got enough armv7 hardware so that cross compiling won't be necessary (the only issue is that compiling will take ages). So if we have enough people who want this, we could coordinate this and make sure that there will be regular ARM releases of recent Palemoon versions.

[freefrog]

Anyone know what happened to the RasPi page?

[Nigaikaze]

Anyone know what happened to the RasPi page?

This happened:
viewtopic.php?f=40&t=15250&p=110167&hil ... pi#p110167

[haggster]

And exactly that could've been avoided, if we had exact instructions available on what needs to be patched in order to get working ARM builds.

Typing this from an obsolete 26.1.1 ARM build.

It's so much faster than FF on the same machine, it's basically in a different league. So IMO it's really a pity that the know-how required to create those builds is lost.

[Moonchild]

That's the problem with people who start these endeavors not documenting what they have done before they vanish.

[Moonchild]

Since someone wanted to pick this back up, opening this thread.

[paulwratt]

I found the original developers page, which linked back to their fork in GitHub. I believe the changes are present there:
https://github.com/dimag0g/Pale-Moon/co ... _RelBranch

BTW I am using the old archived armv7 v26.1.1 binary on Devuan 1 (jessie-stable-old) on a RPi 2B+, with a new "palemoon-arm-install.sh" that is a bit more industrial. The only issues I have had so far is not being able to choose branches on GitHub, and no results from the default DuckDuckGo search (a fix for that is here: viewtopic.php?p=147202#p147202 DDG Lite QS).

If I can get their old v26.1.1 branch to build first, then I am going to see if I can build a v27.8.1 branch for armv6 and armv7

I have had a look at a their last commit to 26.1_RelBranch that imports their changes from 25.8_RelBranch, and apart from one EGL related file contents (slight) change, most are casting addition, specifically to double and float. I believe that there are speed improvement to be had right out of the box without changing anything, simply by compiling with, for and on "armhf" (the original was cros-compiled with eabi, which is soft float).

the original armv7 build string is:

Build platform
target
armv7l-unknown-linux-gnueabi

Build tools
Compiler Version Compiler flags
gcc gcc version 4.7.2 (Debian 4.7.2-5) -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -march=armv7-a -mfpu=neon-vfpv4 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer
c++ gcc version 4.7.2 (Debian 4.7.2-5) -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -march=armv7-a -mfpu=neon-vfpv4 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer

Configure arguments
--enable-official-branding --enable-application=browser --disable-crashreporter --disable-accessibility --disable-parental-controls --disable-webrtc --disable-logging --disable-necko-wifi --disable-installer --disable-updater --disable-websms-backend --disable-tests --disable-mochitests --disable-debug --disable-debug-symbols --enable-strip --enable-jemalloc --enable-chrome-format=omni --x-libraries=/usr/lib --disable-elf-hack --enable-media-plugins --enable-gstreamer --enable-libjpeg-turbo --with-gl-provider=EGL --enable-force-egl --with-arch=armv7-a --with-fpu=neon-vfpv4 --enable-optimize=-O2

I'll first try an RPi 2B+ armv7 build with GCC 4.9 on Devuan 1 (jessie-stable-old) and see if how runs on Raspbian (jessie-stable-old), then we will see how things go (I have an armv6 Wheezy and a RPi B)

Wish me luck

BTW I dont fancy building 361Mb v28beta3 natively ...

Cheers

Paul

[Walter Dnes]

According to old release notes https://www.palemoon.org/releasenotes-archived.shtml Pale Moon stopped requiring Gstreamer as of v27.1.0, and Gstreamer code was entirely removed as of v27.2.0

How memory-constrained is the target arm environment? There's a short thread on the busybox mailing list about reducing gcc bloat. Busybox runs in memory-constrained environments, so the devs try to squeeze down the binary size. See posts http://lists.busybox.net/pipermail/busybox/2012-September/078326.html and http://lists.busybox.net/pipermail/busybox/2012-September/078331.html
Basically they add "-fno-unwind-tables" and "-fno-asynchronous-unwind-tables" to CFLAGS/CXXFLAGS. E.g. on my Gentoo homebrew build, I use
ac_add_options --enable-optimize="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
I've been using it for over 5 years with no problems. On Gentoo almost everything is compiled from source. If these flags were preblematical, I would've foundout "the hard way" a long time ago.

I believe that PM 28 requires SSE2. Does arm handle that?

[Moonchild]

I believe that PM 28 requires SSE2. Does arm handle that?

SSE2 is Intel x86 only. Building for ARM this doesn't apply because it's a completely different architecture.

[paulwratt]

How memory-constrained is the target arm environment? There's a short thread on the busybox mailing list about reducing gcc bloat. Busybox runs in memory-constrained environments, so the devs try to squeeze down the binary size. See posts http://lists.busybox.net/pipermail/busy ... 78326.html and http://lists.busybox.net/pipermail/busy ... 78331.html

on a RPI 2B+ the biggest build issue when using GCC is when it starts using virtual (swap) memory, as even without X running, the 1G is shared with the GPU, then the OS requirements on top of that, which from memory (I will verify this later) reduces usable memory down to 700Mb +. The USB becomes a bottle neck because the kernel is constantly swapping 4Kb blocks in and out, but GCC is still also creating using temp files, also thru the USB. This is why Building GCC on a 1Gb (RPi 2/3) takes 42 hrs, where as on a 2Gb system (TinkerBoard & MiQi) it takes 12 min.

Compared to building GCC, building palemoon is a lot less, even on a bottleneck limited resource like RPi, so it should not take long.

On the SSE front, @Moonchild is right, and you can see it in the build string above. on ARM v6/v7 "hf" the maths is done in the GPU where (normally) v7 has NEON available (which is equivalent to SSE/2 on x86). However for x86 I did notice some info for non-SSE2 builds, have a search/read. I believe this is now a moot issue with v28 beta's with the new XUL engine.


Cheers

Paul

[Moonchild]

I would not recommend ever trying to build Pale Moon on a RPi board. The only way you're going to have a reasonable build time and expected result (and no bailouts because of OOM in GCC) is if you cross-compile on a desktop Linux system with an ARM target (similar to how Fennec is built).