Release Pale Moon


New build on the repo. This time, I cross-compiled it, but it should be the same (same compilation options).
 

Build 16

-----------

  • Update to 25.7.2 sources
 
 
New build on the repo. Still cross-compiled, and this time I used LTO (cannot activate it on the Pandora because of 32bit memory constraint!), so it maybe slightly faster (or not, it's not very clear if it's usefull).
 

Build 17

-----------

  • Update to 25.7.3 sources
 
 
Hello ptitSeb,

I wonder if you have any hints for me as I'm trying to build PaleMoon for my RPi.
I'm trying to build the vanilla sources without your patch (it's for performance and WebGL, right?)
I'm stuck because of assembly functions failing to compile:

libvpx/vp8_vpxyv12_copyframe_func_neon.asm.s: Assembler messages:
143:08.55 /root/Pale-Moon-25.7.3_Release/obj-armv7l-unknown-linux-gnueabi/media/libvpx/vp8_vpxyv12_copyframe_func_neon.asm.s:37: Error: internal_relocation (type: OFFSET_IMM) not fixed up
143:08.56 /root/Pale-Moon-25.7.3_Release/obj-armv7l-unknown-linux-gnueabi/media/libvpx/vp8_vpxyv12_copyframe_func_neon.asm.s:38: Error: internal_relocation (type: OFFSET_IMM) not fixed up
143:08.56 /root/Pale-Moon-25.7.3_Release/obj-armv7l-unknown-linux-gnueabi/media/libvpx/vp8_vpxyv12_copyframe_func_neon.asm.s:39: Error: internal_relocation (type: OFFSET_IMM) not fixed up
143:08.56 /root/Pale-Moon-25.7.3_Release/obj-armv7l-unknown-linux-gnueabi/media/libvpx/vp8_vpxyv12_copyframe_func_neon.asm.s:40: Error: internal_relocation (type: OFFSET_IMM) not fixed up
...
Do these messages look familiar? I understand what the problem is, but I don't see how to fix it easily.

Do you have any special settings in .mozconfig file (other that -fsingle-precision-constant)? Any special pointers (specific gcc version to use, etc)?
 
Last edited by a moderator:
@dimag0g: yes, souds familiar indeed. 

The problem is some optimisation flags that confict with the perl script that extracts some displacement constants...

try this patch:

diff --git a/media/libvpx/Makefile.in b/media/libvpx/Makefile.in
index e6a8853..a6407c3 100644
--- a/media/libvpx/Makefile.in
+++ b/media/libvpx/Makefile.in
@@ -581,7 +581,7 @@ else
# We can extract the asm offsets directly from generated assembly using inline
# asm. This is the preferred method.

-vpx_scale_asm_offsets.s: CFLAGS += -DINLINE_ASM
+vpx_scale_asm_offsets.s: CFLAGS += -DINLINE_ASM -O0 -fno-lto

OFFSET_PATTERN := '^[a-zA-Z0-9_]* EQU'

@@ -593,11 +593,11 @@ GARBAGE += vpx_scale_asm_offsets.s vpx_scale_asm_offsets.asm

ifdef MOZ_VP8_ENCODER

-vp8_asm_enc_offsets.s: CFLAGS += -DINLINE_ASM
+vp8_asm_enc_offsets.s: CFLAGS += -DINLINE_ASM -O0 -fno-lto

vp8_asm_enc_offsets.s: $(srcdir)/vp8/encoder/vp8_asm_enc_offsets.c
$(REPORT_BUILD)
- $(CC) -S $(COMPILE_CFLAGS) $(NO_INTEGRATED_AS_CFLAGS) $(TARGET_LOCAL_INCLUDES) $(_VPATH_SRCS)
+ $(CC) -S $(COMPILE_CFLAGS) -O0 -fno-lto $(NO_INTEGRATED_AS_CFLAGS) $(TARGET_LOCAL_INCLUDES) $(_VPATH_SRCS)

vp8_asm_enc_offsets.asm: vp8_asm_enc_offsets.s
grep $(OFFSET_PATTERN) $< | sed -e 's/[$$\#]//g' \
It should help you.
 
Pale Moon was brilliant when I first started using it, but these days it just sits there from start up, thrashing the SD card on any click, or keyboard input. I've tried resetting preferences and reinstalling but it doesn't seem to make any difference.

Can anybody suggest anything? I've had to go back to Arora. Not as many features, but at least it works at a decent speed...  :(

This question is a couple of months old, but I've recently had to install Firefox in an environment with not-so-fast I/O, and after some troubleshooting I found this explanation and solution: http://www.verot.net/firefox_tmpfs.htm (SQLite is very slow, and Firefox writes to its SQLite files all the time).

That solution is missing the fact that Firefox puts its disk cache under ~/.cache/ I would suggest to set browser.cache.disk.parent_directory in about:config to a directory in the Firefox profile (that's how it used to be in Firefox's early days, if I remember correctly, but I may be wrong). I'm not sure whether Firefox particularly likes it if its disk cache gets disabled entirely, and the RAM cache increased instead.

Also, the script uses rsync on a local filesystem which, as far as I know, causes it to disable delta transmission by default (it just copies whole files), so --inplace --no-whole-file should be added (and the cache directory excluded) to keep writes low. (Can someone verify this? I've not had the time to test this yet.)

I'm assuming that Pale Moon is similar enough to Firefox that all/most of this applies to it, please correct me if that's incorrect.

Your problems /might/ only have occurred now because SD card wear levelling is proprietary black magic, and you've been putting small writes on the SD card for a while now. That's speculation though. You could try doing a Secure Erase of the SD card, which might or might not "reset" it. If you have access to a Windows machine, I would recommend using the Panasonic SD Memory Card Formatting Software over anything else for formating thereafter.

(You might also want to read the ArchWiki entry about SSDs)
 
Last edited by a moderator:
Hi ptitSeb,

I have yet another question regarding the build process, autoconf specifically. What I want to achieve is to build everything with -ffast-math, except sqlite3 which wants to have this option disabled. To achieve this, I have added an option "SQLITE_CFLAGS=-fno-fast-math" to configure.in. After I run "mach configure" I can track that option down to "obj/config/autoconf.mk" where it is copied, and to "obj/storage/build/Makefile" and "obj/storage/src/Makefile" which seem to use it. However, when I try to build, sqlite3.c still throws an error, and the gcc command line for it does not have the "-fno-fast-math" option.

I was able to work around this by including "#pragma GCC optimize "no-fast-math"" into sqlite3.c, but this approach seems kind of hacky. Do you have any idea why my change to configure.in is ignored?
 
Hi ptitSeb,


I'm struggling to ger WebGL working on my system (EGL on Banana Pi with mali 400 GPU), and I have a couple of questions about your port.


1. You have modified gfx/gl/moz.build file to add EGL-related sources to the build, and used custom defines in GLContextProvider.h to set GL_CONTEXT_PROVIDER_DEFAULT to GLContextProviderEGL. Is there a reason you did it this way instead of adding a --with-gl-provider=EGL option to configure? BTW, I tried both ways, but seem to be missing something.


2. In GLContextProviderEGL.cpp, you made 2 modifications: removed a call to sEGLLibrary.fDestroyContext() and replaced a call to CreateEGLPixmapOffscreenContext() by a call to CreateEGLPBufferOffscreenContext(). Can you provide any context to these changes? Are they Pandora-specific, or similar ARM devices like RPi/BananaPi are likely to need them as well? I actually have reverted the changes and I'm now building Pale Moon with DEBUG enabled just for this file, perhaps it will shine some light on the issue.


Thanks in advance and sorry for abusing your support thread with dev questions.
 
Last edited by a moderator:
Hi ptitSeb,


I'm struggling to ger WebGL working on my system (mali 400 GPU), and I have a couple of questions about your port.


1. You have modified gfx/gl/moz.build file to add EGL-related sources to the build, and used custom defines in GLContextProvider.h to set GL_CONTEXT_PROVIDER_DEFAULT to GLContextProviderEGL. Is there a reason you did it this way instead of adding a --with-gl-provider=EGL option to configure? BTW, I tried both ways, but seem to be missing something.


2. In GLContextProviderEGL.cpp, you made 2 modifications: removed a call to sEGLLibrary.fDestroyContext() and replaced a call to CreateEGLPixmapOffscreenContext() by a call to CreateEGLPBufferOffscreenContext(). Can you provide any context to these changes? Are they Pandora-specific, or similar ARM devices like RPi/BananaPi are likely to need them as well? I actually have reverted the changes and I'm now building Pale Moon with DEBUG enabled just for this file, perhaps it will shine some light on the issue.


Thanks in advance and sorry for abusing your support thread with dev questions.

I'm sorry, but I don't remember well the context. I hacked instead of using command line switch, well, that's some kind of reflex now. Tend to hack first and ask question after ;)  I did used command line parameter on Chromium for example, but still had to hack anyway.


Most of the time, I have to hack EGL support to at least force the context creation. Pandora support only 5/6/5 16bits for Windowed context, were most softwares want 8/8/8/8 32bits ones.


Pixbuffer are not really supported on the Pandora IIRC (well, it is supported but need some special memory allocator, same kind as for Texture Streaming) , but PBuffer are... And I don't really recall why I removed the DestroyContext, but I guess it was crashing with it. I'll check the code later, maybe it will rings a bell.
 
Last edited by a moderator:
Thx for this :)


I use nearly only Palemoon on the Pandora for surfing.


A Question:


Is it possible to try a Port of the minimalistic Atom Version on the Pandora?


This Palemoon Atom Version should need a bit lesser Ram and maybe can work faster on the Pandora too :)
 
@ingoreis: I checked, and the Atom build is mainly just the compiler optimisation (nothing usefull for the pandora) and the absence of the Web Developper module. If I see if I can remove it, I'll do...
 
Last edited by a moderator:
New build on the repo, in synch with latest security update (note that I have tried to use the "Atom" build, but I'm really unsure I infact succeeded, this build looks the same)


Build 19


-----------

  • Update to 25.8.1 sources
 
PND Testet it and work good here.


A short test without Internetconnection offered that this Version seem to


use a little little bit lesser Kilobytes Ram on the Pandora.


Also i deleted my old Appdata for the Testing :)


Work good here this Version thx :)
 
Back
Top