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…
2 Likes
Quick build test on Haiku hrev57019 x64:
$> git clone --filter=blob:none -b haiku102 https://github.com/kenz-gelsoft/gecko-dev.git
- Note: About an hour (i.e. 68m) for full git completion.
$> make ./bootstrap
~ Artifact menu: Picked option 2- Firefox Desktop
-
NOTE: I had to install pip3 (Package: pip_python39 22.3.1-2)
- Picked 'no" for data collection, Mozilla commits, and telemetry.
-
NOTE: Your system should be ready to build Firefox for Desktop!
Compared with Firefox 113.0.1 (Linux x64).
2 Likes
@cocobean Thanks trying!
I updated the Wiki info, with my additional test.
I added how much time and disk space it’ll take, required PC resource, prerequisite python3. Especially I forgotten, for the true first time, they asked you about build-time data collection.
What about git clone --depth=1?, this should save time and disk space?
1 Like
Oops, I missed to write about this in the wiki.
I will add it tonight, you need to do following basically:
git clone https://github.com/mozilla/cbindgen
cd cbindgen
cargo build --release
and set PATH env to built cbindgen command lives in target/ dir.
1 Like
Yes, It’s OK for just trying to build. If you will work on the clone, I don’t recommend it (since many git feature won’t work).
2 Likes
There is already a port of FreeBSD and Mac for Palemon and Basilisk, Basilisk’s interface is more friendly!
Wow! Awesome progress, this is super cool to see. Firefox support on Haiku is a dream.
3 Likes
I created a Haiku x64 package and recipe for cbindgen 0.24.3. I’ll post it soon.
Hopefully, we can build a modern Firefox on Haiku x86 as well.
2 Likes
Did you ran a build on 32bit also? (I know it’s a pain to build)
Not yet. Haiku’s X11 Render and RandR extension builds are currently disabled.
Not to distract from the motivation of porting Firefox to Haiku. I was curious if SeaMonkey can be ported to Haiku without a lot of work?
Seamonkey does not support wayland as far as i know.
Thanks! I’ll use once it published and will update build instruction!
Currently my build configuration and focus is with wayland only. I guess Xlibe may build too, but it is also need integration work with OpenGL.
I don’t know if it is even buildable with Gecko 102 ESR. Thunderbird team seems working with some amount of consideration as they shares some code with SeaMonkey. But I suspect it doesn’t work well even if it builds.
2 Likes
As far i know, the Seamonkey’s base is a 60.8 with the updates backported.
2 Likes
But does it have wayland support ?
Build successful. Says to test build, mach run.
3 Likes
I made almost no progress on port itself, but made some progress about debugging firefox. So I shares it.
By hacking Debugger Kit a bit, now I can debug the firefox’s huge libxul.so built with DWARF3 with symbols.
The cause why the Debugger (Kit) failed to symbolicate libxul.so was 0-length CIE.
The CIE(Common Information Entry) lives in .debug_frame section that is defined with fields starting with the length, a CIE ID, a version and augmented follows in this order.
But the length field specifies the length of the CIE struct, and 0-length is not forbidden, so this data may be valid.
The current implementation of the Debugger kit treats this invalid data and ignores whole debug information of the binary.
Just ignoring the section worked for me.
There may be a discussion how this case should be handled, though.
Will file this problem to Trac.
23 Likes
From one page I found when searching:
If
Lengthcontains the value 0, then this CIE shall be considered a terminator and processing shall end.
So I think your changes are correct here. In general I would think any time there is a length field in any file format, 0 should probably always be considered a valid value.
3 Likes