That is what I meant.. What, I was like awake for only 10 minutes when I wrote the post. Are the version numbers not in sync between glib and glibc?

The choices are.. glibc 2.12 (matches EL6) or glibc 2.17 (matches EL7). Obviously Travis was still using CentOS 6 to produce the 32bit builds.. Exactly HOW he managed to do cross-compiling I don't know.. That information is just drawing blanks for me except that there is a record in my head of a procedure but it ONLY works when using the system provided GCC.. it would NOT work using devtoolset UNLESS the build env OS is x86.. And THAT doesn't have any official devtoolset for it.. AND the devtoolset for the x64 version does NOT have packages FOR the x86.. Unless I am missing something.

So what I did was I used a Fedora 32bit version with both what I considered the right combo of compiler and glibc version to produce what got released.. That was after six hours of frantic and unproductive research under what I considered was an emergency situation. Deff not how I wanted to spend my Saturday.

As an update: I am looking into a x86 version of the devtoolset as compiled for and by CloudLinux.. If successful I will be able to build on CentOS 6 and the glibc minimum requirement will be lowered to it's former state. I also have to fudge Python 2.7 on there as well. I will continue down this line of research for the time being. If you people are happy with the performance of GCC 4.9 (which others have reported as working better on purely x86 hardware) I will continue using that compiler version. The choices really are that and 7.3.

But that guy using old ass debian-based whatever should REALLY update his operating system no matter what ends up happening.

Currently I use CentOS 7, but for Pale Moon 27, I used to have a CentOS 6 32-bit chroot on my machine. I also had to build GCC 4.9, which was recommended version at that time, from source while inside the chroot. Another package not available in those repositories was yasm which also needed building from source. And that was most of it other that yum installing Pale Moon build dependencies which are a lot of *-devel packages.

My laptop runs latest Arch Linux and Pale Moon builds produced using method above were fully functional on my system despite a huge difference between "run" and "compile" environments.
Obviously, you can do your own research and this information on chroot is available on the Internet but let me know if you want easy "working" instructions which were adapted from many sources online or want to ask something specific.

Travis also once asked me about how I do 32-builds thinking I was doing something magical like cross-compiling using a 64-bit toolchain, but then he was OK once I told him I was using a simple 32-bit chroot system.

I have to be careful not to mix up GLIB and GLIBC too. GLIB are the GNOME base libraries that GTK+ uses, and GLIBC are the C runtime libraries that pretty much everything uses. The versions of each don't have any relationship.

I have to be careful not to mix up GLIB and GLIBC too. GLIB are the GNOME base libraries that GTK+ uses, and GLIBC are the C runtime libraries that pretty much everything uses. The versions of each don't have any relationship.

Once I get the revised build environment setup I will be adjusting the System Requirements on the Pale Moon for Linux site (and hopefully changing the site software over to my new project while I am at it). So that both the browser's 32bit and 64bit requirements are explicit.

I am currently pushing for 32bit to require older but not ancient systems (continuing to compile with GCC 4.9) while 64bit will continue to target EL 7 level or higher systems.

I will also look into using the GCC 8 for 64bit builds but I will need bare metal testers to ensure stability of builds using it. Failing that GCC 7.x has been doing a pretty good job.

Additionally, 64bit will be getting a GTK 3 build along side it's GTK 2 build. I see no reason to provide one for 32bit since I am pushing for it to be treated as (reasonably) legacy on the Linux.

Keep in mind, kids, that in the absence of Travis (or someone else interim as a Linux Developer) I can only provide so much help and action in the linuxsphere. Mostly giving a few things some attention on a build or infra level. Oh and coordination. I am good with coordination. (And of course giving orders, but you all know that )

Hi kids.. Wanted to update you 32bit guys on the current state of the special build environment required to provide you with binaries for the Pale Moon.

I have constructed a CentOS 6/GCC 4.9 i386 environment that I intend to use going forward. My test build was successful.. This will mean glibc requirement will be back to 2.12 minimum. We are planning a security update soon but I want one or two of you 32bit people to lend me a hand in testing a build from the new build vm.

If you want to help out.. Please be quick about it because that sec release coming up is coming this week. You are the guys who are gonna be using what I push out so it would be nice to know it works properly.

@New Tobin Paradigm Hi! I'm testing new-test binary 32bit from this morning... So far everything seems good. Nothing different from the official releases.

I am checking it through the console to see any warn, browser is launched very cleanly as usual. I'm also using ps_mem to see memory usage + top for CPU usage. about:memory (GC+CC+Minimize memory usage) releases the memory properly. OK everything on this field.

It's been a few hours online since today's morning where I started testing. I have downloaded a few files, also watched Youtube clips.
The performance seems quiet. Chats / Disquss / Blogs / Feeds OK.

The Debian Stable (Buster) builds in my repo, as well as Ubuntu 18.10 and above, are being built with gcc-8, and so far there haven't been any complaints at all about it being unstable.

Is there any news about gcc-9 compatibility work, since that's the default gcc in upstream Debian and Ubuntu?

Thank you for the gcc8 report. I am not going to change it for 64bit this coming release but may in the future. Good to know it looks good but I would like more testing outside of debianspace.

GCC 9 as an option.. Well there was some prelim work that happened but nothing was committed toward that end. I suspect that will change in the near future. Do want to keep compatibility so the patches would need to take that into account.

The 32-bit build works fine on Puppy Slacko 5.4 (refurbished Lenovo laptop), just like the 28.6 series. It does not launch on 5.2.x series Puppy linux. So this build matches Pale Moon 28.6 series for backwards compatability.

On another note, Gentoo linux is now on gcc-8.3.0. My homebrew builds for my 64-bit desktop run just fine, so that's a good sign.

Yeah, that won't be a problem Thursday. If you want to grab that 28.7.1pre to tide you over.

If you read this thread you would know this has been one of the main topics discussed. Did you fully read this thread before posting?

Also, why did you wait so long before updating? It's been just over a year. Do you not believe in updates? You do know much has changed since the second release of Pale Moon on UXP including dozens of critical security fixes.

Quite frankly I am not happy with the combination of obviously old hardware, operating system, and lack of keeping up on browser updates.