I have a roadmap (not written anywhere yet) to make this port success and to be sustainable. Key is to upstream our changes (again) into Mozilla main development.
Up and running with small changes as much as we can
This is important for two reason
smaller changes may be easier to upstream
smaller changes make rebasing easier
I’m working on this targeting Firefox ESR(extended support release) 102 branch because
it doesn’t require dependencies up-to-date
it is is currently supported
it’s not moving target.
Upgrade dependencies to newer
for next step
Rebase porting effort to Firefox main branch
Make existing tests PASS (or mark them as known to FAIL)
Start send patches to upstream from trivial changes
Once we have test coverage, it’s much easier to import upstream changes (new Firefox version feature), to know build bustage, to investigate what change broke our build.
Once fully upstreamed, they(Mozilla) at least consider conflicting code. This also helps us to import upstream changes much more.
We will keep fork repo/branch after the upstreaming done, there is the place we have Haiku-specific relative large implementation that improves UX more. Upstream them one by one if its reasonable.
This is a good roadmap. I’d suggest also writing a “How to compile Firefox for Haiku” post or doc, this makes it easier for others to start contributing.
I have another (yet private) github repo tracking this project and it has my struggling record (almost personal notes). There are some to share for people to look closely or attempt hacking this.
Now I have gecko-dev fork github repo that I shared in this topic. Issues related the code should be convenient in that repo, so I will move some informative open Issues there in coming days.
Would it be possible to build just Gecko and not all of Firefox, initially? Gecko isn’t as conducive to embedding compared to WebKit and Bink, however Jolla Browser (Sailfish OS) and KaiOS have managed to do this. Perhaps it may be possible to create a Gecko-based web browser directly using the BeAPI?
Yes, Of course. I’ve checked all patches for BSDs when encountered build errors.
On Linux, some distros packages (or provided in the past) GRE(stands for Gecko Runtime Environment) XULRunner which is for embedding. This package I believe Eclipse used and some other Linux programs embedded Gecko with it.
But it is abandoned officially long time ago by Mozilla, so very old version of Gecko was available or maintained by the community and maybe recently it is not available AFAICT.
Though I don’t know about Sailfish OS browser, KaiOS inherits FirefoxOS legacy, which builds its UI with the HTML5 technology with enhancement. It is effectively Firefox for Android without UI, so can’t be used for embedding.
Currently Thunderbird and SeaMonkey(old Mozilla Application Suite) are only users of Gecko as a platform, they are XUL application(XUL=XML+JS application description language).
Jolla or Sailfish Browser is the web browser based on gecko 78 esr and using embedlite (also known as IPCLiteAPI), a lite-weight embedding API from Mozilla.
As first screenshot I shared, Debugger failed to find C++ symbols, this made debugging nightmare.
This seems the same problem with the following topic,
I searched around workaround about this but I have no luck.
Finally, I tried building Firefox source with GCC (instead of default Clang). But it failed because libxul.so is too large (0x4864c809 bytes = 1,214,564,361 bytes = 1.2GiB).
75:48.07 toolkit/library/build/libxul.so
81:10.04 /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/11.2.0/../../../../x86_64-unknown-haiku/bin/ld: error: libxul.so(.debug_info) is too large (0x4864c809 bytes)
Partially rebuit with GCC, Debugger could find symbols partially. Anyone have workaround this?
Always used printf’s back in the days, we didn’t have a good debugger back then. Debug info is often huge, perhaps remove the one for libxul.so. If it is part of lib you can use strip. If it is a VM give it more memory or add swap.
You can force the type of debug info by giving the correct flags to the compiler, I think? In gcc you can for example use -gdwarf-3 which forces version 3 of the DWARF debug info spec. I suspect clang has similar flags? But in the linked topic this was already tried and wasn’t working. Probably Debugger was only tested with gcc executables and doesn’t accept the format that clang is using for some reason.
If that’s the case, I don’t have any advice besides, you will need to debug the debugger and fix the DWARF loading (that’s how it often goes in Haiku, you start with porting an app and you end up debugging some parts of the OS instead ). And if the files are too large, it’s possible clang will have similar problems. You may save a few megabytes by doing export DISABLE_ASLR=1, supposedly gcc has this already done by default but I’m not sure if it works.
I want to debug this huge library, so this is not an option…
I’m using bare metal to build it’s old but has enough 16GB RAM to successfully build 1.9GB libxul.so with debug info in case of Clang. So maybe I hit Haiku GCC bug or limitation.
I found Mozilla’s build system explicitly specify -gdwarf-4 maybe for debugging compatibility with latest Clang which generates DWARF5 as default.
Indeed built product contains DWARF4 as far as I checked with llvm-dwarfdump. I thought Debugger supports DWARF4 but generating DWARF3 has chance to improve the situation. So I’ll try DWARF3 tonight.
(clean build takes some hours…)
Not a good idea, since Pale Moon has historically been hostile to ports that attempt to use system libraries:
Considering that avoiding static libraries on Haiku is common practice, anyone submitting a recipe for Pale Moon on HaikuPorts would run into the same problems that an OpenBSD ports contributor did.
Also related since Pale Moon has similar branding policies as Firefox, perhaps it might be a good idea to disable official FF branding until patches are upstreamed? Mozilla doesn’t usually enforce theirs as strictly, with the most notable example being with Debian and IceWeasel (which has since been resolved).
There is support for system libraries in the platform, though you can’t brand a binary as Pale Moon without some requirements being checked.
@KENZ Firefox’s libxul is obscenely large for linkers, you might have better luck with Pale Moon as its libxul is being split in order to make linking and debugging easier.
Does Pale Moon accept patches for platform enablement? If not, then it may be more difficult in the long-term to maintain a Pale Moon port instead of Firefox.
DWARF3 works, I’ve just built Genio with clang and Debugger seems to correctly handle the new executable.
I haven’t conducted a thorough test, though.
We need to investigate to understand whether this is a problem with Debugger or clang’s output.
IIRC, someone was working on porting LLVM 15 or even 16 (not sure if it’s @X512) and if the new version may fix this problem.