Compiling Pale Moon on Void-linux - gcc-9.10
Posted: 2019-06-30, 09:22
I concur, build finnishes here too, thank you for patch! 
Pale Moon forum
Discussion forum for the Pale Moon web browser
https://forum.palemoon.org/
Compiling Pale Moon on Fedora >= 30
Page 2 of 2
Re: Compiling Pale Moon on Fedora >= 30
Posted: 2019-10-16, 16:17
Right, the GCC 9 issues have been figured out partly thanks to some work bgstack did (assuming he is still hanging about) and of course the rest of us. I cannot attest to the general stability and reliability of GCC 9 builds at this time but as soon as I land these couple of patches onto trunk it will, at the very least, resolve buildablity issues.
Re: Compiling Pale Moon on Fedora >= 30
Posted: 2019-10-16, 16:46
Re: Compiling Pale Moon on Fedora >= 30
Posted: 2019-10-17, 19:25
Nice! But I take it that if a lower version of gcc than 9 is readily available in the distro, it's still preferable to force the build to use that, correct? I'm getting ready to do that in my OBS repo when they add Ubuntu 19.10 support, since that will have gcc-9 as the default gcc, but will still have gcc-7 and -8 available.
Re: Compiling Pale Moon on Fedora >= 30
Posted: 2019-10-17, 20:06
When doing system packages you, if possible, should use the system provided developer tools native to that distro version. In many distros the system compiler will have it's own revisions and bug fixes outside just newer gcc for the life of the version. So no you don't have to force it. We just needed you to because the newer stuff wasn't well tested or busted.
One of the lasting changes that has come when I temporarily assumed the role of Linux Team Leader is that we are gonna try to be quicker on the uptake of identifying and hopefully solving issues in regards to newer compilers, glibc, that shit in general.
Also, while this isn't a change in policy perse I do want to reiterate that system packages should be adapted to the systems they are targeted at. Of course this is within reason and well specified of what not to try and sneak by us.. But I just feel that for the most part, that is the whole point of DOING system packages else why not just use the generic builds after all.
The one thing about system packages targeted at specific distros and versions thereof is that if you do need to do something that might stray past the usual, the packagers should feel free to ask. Assuming something is ok will only mean the answer is no.. Asking means the answer might be yes specifically for you! Doing it anyway and we finding out about it after the fact, weeeeeeellllll.. I think we know what happens there and it never ends well no matter who is in the right and who is in the wrong. So ask, kinda like our good and dear debian-related friend stevepusser did
One of the lasting changes that has come when I temporarily assumed the role of Linux Team Leader is that we are gonna try to be quicker on the uptake of identifying and hopefully solving issues in regards to newer compilers, glibc, that shit in general.
Also, while this isn't a change in policy perse I do want to reiterate that system packages should be adapted to the systems they are targeted at. Of course this is within reason and well specified of what not to try and sneak by us.. But I just feel that for the most part, that is the whole point of DOING system packages else why not just use the generic builds after all.
The one thing about system packages targeted at specific distros and versions thereof is that if you do need to do something that might stray past the usual, the packagers should feel free to ask. Assuming something is ok will only mean the answer is no.. Asking means the answer might be yes specifically for you! Doing it anyway and we finding out about it after the fact, weeeeeeellllll.. I think we know what happens there and it never ends well no matter who is in the right and who is in the wrong. So ask, kinda like our good and dear debian-related friend stevepusser did