Compiling Pale Moon on Fedora >= 30 Topic is solved

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
User avatar
biopsin
Fanatic
Fanatic
Posts: 119
Joined: 2016-02-07, 17:15

Compiling Pale Moon on Void-linux - gcc-9.10

Unread post by biopsin » 2019-06-30, 09:22

I concur, build finnishes here too, thank you for patch! :think:
voidlinux_x64 glibc-2.38 / Palemoon_latest release (gcc-13.2.0) / GTK2

New Tobin Paradigm

Re: Compiling Pale Moon on Fedora >= 30

Unread post by New Tobin Paradigm » 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.
Last edited by New Tobin Paradigm on 2019-10-16, 17:10, edited 1 time in total.


User avatar
stevenpusser
Project Contributor
Project Contributor
Posts: 903
Joined: 2015-08-01, 18:33

Re: Compiling Pale Moon on Fedora >= 30

Unread post by stevenpusser » 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.

New Tobin Paradigm

Re: Compiling Pale Moon on Fedora >= 30

Unread post by New Tobin Paradigm » 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 :thumbup:

Locked