Yes, I will write it.
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.
Can you consider openbsd and freebsd port patches ?
It might be useful for Haiku port.
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).
So, embedding with BeAPI is hopeless…
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.
Thanks to inputs.
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).
Disclaimer: I am not a legal expert.
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.
Thank you comments!
Yes. We need our own (or choose safe existing one) branding until Mozilla authorizes us to call our work (not yet!!) Firefox officially.
I have a proposal for the name and icon motif as a project starter, but discussing it is too premature.
Although I have no interest to port PaleMoon, but using more system libraries may help this situation, thanks.
The FreeBSD port of Firefox also in favor of using system library. It reduces system wide disk usage and helps keeping patchset size small to build.
Thank you for info. But DWARF3 debug build didn’t work for me…
Is Fennec still around as the alternate branding?
@tqh I wrote up this. This instruction may lack some information and has some mistake, please inform me if you find what didn’t work well.
Nice and clear instructions! I expected a lot more hacks to get the build working.
I probably won’t have much time to build myself, but you never know…
