Compiling Pale Moon on Fedora >= 30 Topic is solved

Support and discussions for the x86/x64 Linux version of Pale Moon.

Moderators: trava90, satrow

User avatar
biopsin
Moonbather
Moonbather
Posts: 53
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.30 / Palemoon (latest release) (gcc-9.2)

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6184
Joined: 2012-10-09, 19:37
Location: Sector 001

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.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast


User avatar
stevepusser
Astronaut
Astronaut
Posts: 530
Joined: 2015-08-01, 18:33
Location: California

Re: Compiling Pale Moon on Fedora >= 30

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

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6184
Joined: 2012-10-09, 19:37
Location: Sector 001

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:
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

Post Reply