In one of my more crazy moments I had the same idea like you to update gecko-dev but unfortunately already failed to compile the current version.
Once you reach a point where work is easy to be distributed you might want to add some hints on how to build the beast. Until then I’ll continue enjoying the show and applaud your bravery! 
@simonschmeisser: I answered you over on GitHub in case you want to give it another go (sorry that I didn’t notice your question earlier). If you hit any other glitches let me know if I can help: it’d be great to have you onboard with this.
Thanks a lot, I hope I didn’t divert you too much.
I think I found a probable cause for the segfault issue you wrote about:
cargo:warning=during RTL pass: expand
...
cargo:warning= float sign(float a) { return copysignf(1.0f, a); }
I pretty much matches gcc bug 90075 so I decided to see if the SailfishOS gcc package already has the upstream patch, and it does not.
I downloaded the sources and quickly realized SFDK wasn’t going to do the trick, so I installed Platform SDK first time in years! I added the patch to gcc.spec file and with a little persuasion was able to apply it, so now all I have to do is figure out how to compile the beast…
I’m an absolute beginner with Platform SDK. I’ve built a few userspace packages with it a long time ago, but compiling these more customized “core” packages is another thing altogether. I’ve quickly combed through the documentation about Building Packages, but that doesn’t really provide help for this package…
I would really appreciate if someone could point me to some instructions! I’ll try to regenerate the patch tomorrow and make a pull request, but without any external help I’m unable to even build-test it myself.
Do you have a link to the massaged patch?
Amazing detective work! That bug definitely has a lot of the characteristics and definitely worth further investigation. Is it the gcc package directly that you’re planning to build?
The Platform SDK is very similar to the Application SDK in concept. The docs have some info and there’s also command-line help (not as extensive as for sfdk I think):
sfossdk
mb2 --help
The main difference from the Application SDK is that rather than executing commands outside of the engine, you have to first enter the engine and then run your commands from there.
So whereas for the Application SDK you might execute:
git clone git@github.com:sailfishos/gcc.gitfic
cd gcc
sfdk build -p -d
(run the prepare step and build with debug symbols)
On the Platform SDK you’d first go into the SDK, then run the command using mb2:
git clone git@github.com:sailfishos/gcc.git
cd gcc
sfossdk
mb2 build -p -d
If you want to set a target you can do it on the mb2 command:
sdk-assistant list
mb2 build -d -p -t SailfishOS-4.5.0.16EA-aarch64'
Sorry if this stuff is all already obvious to you, but in general there shouldn’t be too much more that you need to know than this (famous last words!). Is there a gcc-specific issue that you’re hitting?
@nephros Not there quite yet, but soon! I’ll regenerate it today and open a PR. I think that’s the most effective way to get it going. I can then tackle the build process on my own.
@flypig Thanks for the condensed introduction! It appears that they are not so far related as I expected, but sfdk sure abstracts a lot of the inner workings away to make development easier in the common case!
So far I’ve had little luck with mb2 and have had to invoke rpmbuild directly, so clearly I’ve gone astray very early on… Luckily, that does apply the patches in order, so that completes my immediate task. I’ll try again after I’ve made the PR with the patch, even if it doesn’t build yet for me.
There is now PR#4 that (hopefully) fixes the issue!
I’ll create I created another thread for the compilation discussion to keep this thread clean 
Interestingly:
Removing the -O1 or -fPIC arguments allow for successful compilation.
For @flypigg, it was O2 causing the issue.
Just wanted to add that I really enjoy the format and the effort put in, than you @flypig !
This seems to be even more adventurous than porting SFOS to a new device, and it will have a much wider impact when it succeeds!
I want to take some time to point out that this is indeed a burnout-prone activity and that you should space out your progress as much as you need.
There are 17 updates in the last 17 days. but nobody would bat an eye if there will be 10 updates in the next 30 days or even less. So please take care of yourself. I have made a livecasting of porting notes of ~60 days and it spanned half a year.
What you should do is just keep the branch(es) up to date. As you can see, in this project’s case, there is no specific device needed for someone to reproduce the same errors as you. So there are chances some might (as they already have:)
Also, I would like to turn the tables on Mozilla and, when this has a conclusion, write them that the qtmozembed we use really should be pushed back in, using your effort as a stance. There is really no way one man can follow tens of people over tens of years refactoring, as was not easy for even a small company such as Jolla to do.
Anyway, really great stuff. I personally appreciate you explainig the reasoning and your knowledge or lack of it for every step.
Hats off!
Just in case you haven’t already found it: there’s a page mapping the commands between the Sailfish SDK and the Platform SDK: SDK ↔ Platform SDK Command Map | Sailfish OS Documentation
That might help you get familiar with the Platform SDK.
I’m happy to hear you’re enjoying them @vlagged! Thank you for your consideration and the useful advice, which I will take it on board.
So far progress is slow but steady, and I’d love to get to the point where we can maintain gecko on a more rolling basis, but I think we’re still a way from that unfortunately. Any way we can persuade Mozilla to make it easier for us will generate dividends in the long run.
I have made a livecasting of porting notes
Were they recorded? If so, could you share a link?
They’re here on the forum. But nowhere near your clarity. I did used them to get back to where I made some decision or skipped resolving a problem. Or really just remembering a command.
I am linking to them just so you notice the pace change of the dates, or the taking of breaks:)
Is there really no way to test your code earlier? Always starting a full build and effectively waiting a day is immense painful.
I would have hoped there is a way to build a smaller chunk only that is way faster.
(I already feel massively crippled if my code-unittest cycle is longer than 60s. )
You raise a good point @thigg. I am doing incremental builds which are quicker than full builds, but as you can tell from my diary they can still take a while to run. I should probably be using partial builds more effectively. This has always been one of the challenging aspects of gecko development.
Today will be day 40! Thanks for doing this journey and writing about this!
Thanks for following along @thigg! You’re right, it’s day 40, but it’s not yet reached the end of Stage 1 (of 3) yet, so no stopping any time soon!
I hope your burnout detector is still running very well. If you take time off, do it with a feeling of great accomplishment please!
I am impressed by the work you’re doing besides your daily work. (and very glad you are writing about it)
I have one tiny suggestion for the blog. Always thought it was problem with esr78, but even on desktop some lines don’t fit in the code blocks (or maybe they do in 4k?), I would suggest changing pre’s white-space to ‘break-spaces’ in bokeh.css, seems to preserve the rest of formatting while also wrapping the super long ones (at least on desktop, not sure how to test on phone). Thanks a ton for the daily read!
Thanks for suggesting this @throwaway69, it’s a nice idea. I try to break lines at 80 characters in all the preformatted blocks, but that’s still way too wide on smaller displays.
After making this change I’m a bit concerned that things may look a bit messy, but let’s see how it goes.