Repositories for supported Debian, Raspbian, and Ubuntu releases

[stevenpusser]

The only trick is more ram. There are gonna be more objects albeit smaller ones to all go into linking libxul. That is a result of the work we are doing.

I don't think more RAM is the answer, since my build laptop has 16 GB available and never comes close to using all of it--32-bit builds use less RAM, in fact. It seems like it's running out of something like "file handles" or whatever only on the 32-bit side of things, which I guess can't provide enough like the 64-bit builds. Plus it's definitely linked to the version of gcc being used. 4.9, 5, 6, and 7 all succeed, but not gcc-8 or 9. https://build.opensuse.org/package/show ... r/palemoon

I was able to build the MX 19 Buster version by using gcc-7 from the Buster repo instead of the default gcc-8, but somehow the bit of code I added to do that automatically doesn't work in the OBS environment.

There's a guy building versions for Devuan Sid on the OBS, and he can't build his version on 32-bit either.

Debian recently had basically the same problem recently with a version of Chromium and 32-bit packages, built with clang, but fixed it by "reducing debugging symbols to avoid memory exhaustion while linking", by changing the compiler flags.

Should I start a separate thread for this, or raise an issue on Github?

My mozconfig is:

Code: Select all

mk_add_options AUTOCLOBBER=1
export BUILDING_RELEASE=1
export MC_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export MC_PALEMOON=1

# Official Pale Moon branding. Please see https://www.palemoon.org/redist.shtml
# for restrictions when using the official branding.
ac_add_options --enable-application=palemoon
ac_add_options --enable-official-branding
ac_add_options --enable-official-vendor

# Disable add-ons signing
# Disable checking that add-ons are signed by the trusted root
MOZ_ADDON_SIGNING=
# Disable enforcing that add-ons are signed by the trusted root
MOZ_REQUIRE_SIGNING=

# Standard, approved Pale Moon build options.
# Enable stuff
ac_add_options --enable-av1
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-devtools
ac_add_options --enable-jemalloc
ac_add_options --enable-optimize="-O2 -w"
ac_add_options --with-pthreads
ac_add_options --enable-strip
# Disable stuff
ac_add_options --disable-debug
ac_add_options --disable-eme
ac_add_options --disable-gamepad
ac_add_options --disable-necko-wifi
ac_add_options --disable-tests
ac_add_options --disable-updater
ac_add_options --disable-webrtc
# Disable telemetry reporting
export MOZ_TELEMETRY_REPORTING=
# ac_add_options --disable-crashreporter
# ac_add_options --disable-accessibility
# ac_add_options --disable-parental-controls

# Options for creating a system package
ac_add_options --x-libraries=/usr/lib
ac_add_options --prefix=/usr

# Builds use all available cores by default--enable and tune this option to
# reduce CPU use and memory consumption during builds. RAM use seems to be about 
# 0.75 GiB per thread. "-jX", where X=number of threads for the build. Example: 
mk_add_options MOZ_MAKE_FLAGS="-j4"

I reduced the number of build threads so I wouldn't need as much RAM on the OBS, since asking for a 14-16 GB "worker" means a long wait before they are available--but even a single thread build still fails on a 16 GB machine.

[New Tobin Paradigm]

Try disabling linux debug symbols for 32 bit.

[stevenpusser]

Well, you've lost me already--remember that I'm not a coder.

I assume that that this line already in mozconfig is not how that's handled, then:

Code: Select all

ac_add_options --disable-debug

[New Tobin Paradigm]

Try --disable-debug-symbols

[Moonchild]

Try --disable-debug-symbols

I actually looked into this a little and it seems that option is only used to pass specific debug flags directly to the compiler. In disable state it doesn't do anything, only with --enable-debug-symbols={flags} does it have an effect, if I read all this correctly.

[New Tobin Paradigm]

Guess so. At most it affects Windows and not Linux without specifying stuff.

Anyway, I will start up my CentOS 6 32bit machine and see if RedHat or someone on COPR was kind enough to offer devtoolset-8 to it and see if it builds or if it runs out of the 6gbs assigned.

[New Tobin Paradigm]

Dunno what else to suggest.. This does not seem to be a 32bit GCC issue but a Debian issue.

[stevenpusser]

Well, yes, also including Ubuntu and Mint, of course. I wonder if they can run the 18.04 32-bit version successfully on the newer releases--or if Mint could build it for their repos using gcc-7, since Ubuntu still has that as an option. That's how I got the Debian 10 based version built for MX 19.

I see than most of the armhf 32-bit architecture builds succeeded on the OBS, even with gcc-8 or 9, so that's even more confusing. Only Ubuntu 20.04's armhf build failed with the same old

Code: Select all

[14911s]     INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")
[14911s] 
[14911s] /usr/bin/ld: final link failed: memory exhausted
[14911s] collect2: error: ld returned 1 exit status

[Moonchild]

I'm afraid we'll end up with this problem on more 32-bit Linuxes unless architecture cross-compiling is an option (that is the way MSVC 32-bit is built on Windows; 64-bit compiler and linker outputting 32-bit binaries and libs).

Of course it would be a possibility to build unified on 32-bit Linux by making the build system treat things conditionally different, but I'd really prefer to avoid that. It's a lot of extra work to set up and maintain.

[New Tobin Paradigm]

I don't think 32bit linux is worth the extra trouble.. It will work or it won't depending on distro, deps, phase of the moon, sunspots, whatever. All I can say is we are at the edge of what 32bit will allow us to do. MAYBE splitting shit out from libxul will stave it off, maybe more code cleanup will stave it off, but come on.. It is 2020 and this is a web client. It has to have a bunch of shit and 32bit just ain't gonna cut it forever.

[Pentium4User]

The i386 build for Debian are still used by people who don't have a amd64/Em64T compatible CPU.
There are a lot of them, think about most Pentium 4, some Pentium Dual Core, Pentium M, Intel Core Duo and Intel Atom Z5xx and N270 N280 that were still sold in 2011.

[New Tobin Paradigm]

Stop using 10+ year old hardware. I been 64bit since 2007 when I built my AMD Sempron 64 machine. That machine that was used for a time as a hackintosh with the last GOOD version of OS X being 10.4, brushed metal UI aside.

You can get previously owned 64bit machines, re-certified business systems that are 64bit for 250 bucks.. There simply is no excuse.

[stevenpusser]

OK, I used the Google to search for similar build errors, and using this in the mozconfig fixed the errors, at least in Debian Buster and Debian Jessie i386 builds on my machine that were erroring out before:

Code: Select all

ac_add_options --enable-optimize="-O2 -Wl,--no-keep-memory -Wl,--reduce-memory-overhead"

As far as I can understand it, this will make the linking take somewhat longer while it uses less memory, but I didn't really notice it taking much longer.

Another suggestion was to use "Os" instead of "O2", but I figured that was less desirable. I also gathered that just throwing more RAM at the problem is useless--somehow the linker can only access something like 3 or 4 GB max on 32-bit architectures. I uploaded an update to the OBS, so let's see if that works. 64-bit users will also get the update, but can refuse it for now.

Update: yes, all i386 builds are now succeeding on the OBS. Woot! Armhf builds are all waiting for available workers, as usual.

[New Tobin Paradigm]

Nice, will add that to the build instructions eventually.

You sure there are supposed to be commas?

[stevenpusser]

I just copied the flags from a thread that had them in that format, and they worked, plus I'm pretty sure the commas are necessary, judging by how I see Debian pass compiler flags to builds from the rules file for other packages. The build errors out if there are any flags in mozconfig that it can't understand. Maybe I can use both memory flags after the first -Wl to shorten the command--I'll try that later tonight.

[stevenpusser]

I was just reading the new Linux Format today, and they had several features on 32-bit Linux and distros that still support it. One point they made it that though you can throw more more RAM on 32-bit systems with PAE, a single process can still only access a maximum of 4GB, and linking is a single process. They also said something about Firefox being unbuildable on 32-bit systems for years now because of this, though I think many distros may do the same kind of trick with clang or whatever they use to build it now.

[New Tobin Paradigm]

Most distros still build Firefox with GCC. We checked around. GCC -O2 while Mozilla's generic build is now Clang -O3.

Anyway, if those optz get the job done go for it just make sure and test.

Still, Linux 32bit is really past its prime and people need to start to upgrading their hardware and get off it. It is time now.

[Pentium4User]

Still, Linux 32bit is really past its prime and people need to start to upgrading their hardware and get off it. It is time now.

I agree that Linux ix86 is old-ass, but it is still needed. Think about notebooks with Atom N270/N280 and most Pentium 4 and Intel Core Duo/Pentium Dual Core.
These are often still used and can't be easily replaced due to missing money.
I also haven't found a laptop with LPT port and a 64 bit capable CPU.
I still use Debian i686 on that, I would prefer x86_64, but it isn't supported by the Pentium M.
For performance, I see no reason to replace it for forums it is ok.

[Moonchild]

I agree that Linux ix86 is old-ass, but it is still needed. Think about notebooks with Atom N270/N280 and most Pentium 4 and Intel Core Duo/Pentium Dual Core.

people need to start to upgrading their hardware and get off it. It is time now.

If you're still running a P-IV in 2020 you really need to re-think what you're doing, and certainly don't expect us to keep making software available for it.

[New Tobin Paradigm]

I don't want to have this argument or at least not in this thread but do know that Linux 32bit is simply going to be a problem that can't be avoided eventually. May even be an issue on Windows one day too.

Just need to stay mindful and realistic about it.