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).
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).
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).
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.