Questions about building 32-bit unstable

[ketmar]

How realistic is it to build Pale Moon on Pentium 4 / 1472 MB RAM, Xubuntu Xenial 32 bit?

i myself wouldn't even try. you definitely need more than 4GB of RAM for any sane build times even on 32-bit system. mine has more than 4GB. with only 4GB you will prolly need to boot into single-user mode, with all demons not loaded and such. with anything less you will prolly see your grandchildren raising their grandchildren before it finishes. ;-)

[jobbautista9]

with only 4GB you will prolly need to boot into single-user mode, with all demons not loaded and such.

Unless you mean 4 GB of RAM without swap (which is bad), it's not that bad. I built 28.15 with gcc 10, 4 GB of RAM, and 5 GB of swap. The only things open are xfce, and an stterm terminal running the compilation. It took only about 3 hours to build. I even used -O3 optimization (it's unpredictable when it will break though, so I don't recommend using that. The resulting browser build seems to work fine so far though...) and gtk3 (doesn't seem like there's any difference with that).

If I encounter a bug though, I will revert back to stevenpusser's debian builds.

[stevenpusser]

32-bit builds fail on my Xenial platforms in the OBS repo, though 64-bit succeeds. The same holds for 32-bit on Debian Jessie, so I'd expect it's something to do with the gcc version. They aren't exhausting memory during the linking, which is another problem that other 32-bit builds can have, but my builds work around.

I also have to limit Debian Sid and Ubuntu Groovy builds to one thread currently for all architectures--it seems to be a bug in make there. Since it's all building up in the cloud, it's not really painful to me--they just take longer.

[New Tobin Paradigm]

If you are swapping or hitting the pagefile on linux or windows respectively when compiling you are gonna have an unstable result. It may lead to instability and subtle corruption of data in the resulting runtime that may not be instantly noticable but it is there. Strange things happen during the compilation process when not confined to real ram.

Also, compiler timings and order of operations will be far more likely to get way misaligned when this happens. Fact is if you don't have the reasonable requirements for building.. Don't. I don't know why I need to constantly repeat this but building UXP is not at all like building your bog standard gnu project. So stop and either download more ram or reconsider why you are even compiling to begin with.

[ketmar]

with only 4GB you will prolly need to boot into single-user mode, with all demons not loaded and such.

Unless you mean 4 GB of RAM without swap

yep. i turned off swapping many years ago.

[artenaki]

How complicated it is, guys. I didn't think before that compiling such a sensitive thing. I have compiled a lot of programs, but they were quite small. GCC took a long time, but it didn't waste much memory and everything worked.

32-bit builds fail on my Xenial platforms in the OBS repo, though 64-bit succeeds. The same holds for 32-bit on Debian Jessie, so I'd expect it's something to do with the gcc version

For Xenial, you can take GCC 9 from the PPA and specify -std=c++14, but it may not be possible the OBS environment. Or use gcc-mozilla (7.5 instead of 5.3).

[Moonchild]

How complicated it is, guys. I didn't think before that compiling such a sensitive thing.

That is what happens when what you compile is over 20 million lines of code that is all tightly intertwined, written over decades by thousands of different people.
It inherently becomes something that is incredibly complex and is pushing the boundaries of what a compiler can do -- you can say it's pretty much outside of design scope for the compilers in use.

[artenaki]

That is what happens when what you compile is over 20 million lines of code that is all tightly intertwined, written over decades by thousands of different people

I understand, but I thought there was a queue. I'll try to build anyway. I'm curious to see what happens.
Do I understand correctly that a build made in Debian 10 will not start in Ubuntu 16.04 due to glibc?
OBS is an alternative. Xenial is still supported there, it's my favorite distribution.
Builds are also available in the MX Linux repository http://mxrepo.com/mx/repo/pool/main/p/palemoon

[moonbat]

Do the generic builds for Linux not work for you that you have to compile it, given that you're not exactly working on browser development?

[stevenpusser]

I don't know if it's possible to add a PPA to the OBS, but I have done that for Ubuntu "virtual machine qemu schroot sbuilds" in the past to get gcc-5 on Trusty. It's sort of a hassle to set one up, so I'm also curious as to what's wrong with the universal binary from Pale Moon itself.

No, a deb built on Debian Buster very probably is not compatible with Ubuntu Xenial.

[artenaki]

Do the generic builds for Linux not work for you that you have to compile it, given that you're not exactly working on browser development?

Everything works so far. In the future I expecting that official 32-bit builds will stop publishing and I would like to get build experience in advance. Actually, I only use Pale Moon for a small number of simple sites (although it's certainly a great browser). Even the old version 28.15 will be enough for me for a very long time. I just imagined the situation: 29 is released, 32 bits are not available anywhere, but I build it for myself. It's like an exclusive. I used (am) 28.2.2 and 28.14.2 builds, which are also not available on the server (there are other close versions, but not such). This is also exclusive. And besides, I would like to get experience with building a browser, I have never done that.

I don't know if it's possible to add a PPA to the OBS, but I have done that for Ubuntu "virtual machine qemu schroot sbuilds" in the past to get gcc-5 on Trusty. It's sort of a hassle to set one up, so I'm also curious as to what's wrong with the universal binary from Pale Moon itself.

Have you tried gcc-mozilla? This package is available in the official Ubuntu and Debian repositories specifically for building Firefox with a newer compiler. Although, newer versions of Firefox are now compiled with clang. Therefore clang is now backported too. For example, Xenial has clang 8 (2019). But on Debian Firefox ESR is still built with gcc.

[stevenpusser]

I'll take a look at gcc-mozilla. Hopefully, I don't have to do any tricks in mozconfig or debian/rules to get it to replace the default gcc.

[artenaki]

Hopefully, I don't have to do any tricks in debian/rules

Apparently you have to. This is how it is implemented in Debian Jessie:
http://security.debian.org/debian-secur ... ian.tar.xz /debian/rules

Code: Select all

ifeq (jessie,$(DIST))
CC := /usr/lib/gcc-mozilla/bin/gcc
CXX := /usr/lib/gcc-mozilla/bin/g++
export LD_LIBRARY_PATH := $(if $(LD_LIBRARY_PATH),$(LD_LIBRARY_PATH):)/usr/lib/gcc-mozilla/lib
endif

Code: Select all

override_dh_shlibdeps:
	LD_LIBRARY_PATH=$(shell echo $(LD_LIBRARY_PATH) | sed -E 's,:?/usr/lib/gcc-mozilla/lib,,g') \
	dh_shlibdeps -a -l$(CURDIR)/debian/tmp$(LIB_DIR) -- -xlibgtk2.0-0

Simply creating symlinks may not be enough. By default, libs will be loaded from the old system directory /usr/lib/x86_64-linux-gnu/

Code: Select all

sudo ln -s /usr/lib/gcc-mozilla/bin/gcc /usr/local/bin/gcc
sudo ln -s /usr/lib/gcc-mozilla/bin/g++ /usr/local/bin/g++
sudo ln -s /usr/lib/gcc-mozilla/bin/cpp /usr/local/bin/cpp
sudo ln -s /usr/lib/gcc-mozilla/bin/c++ /usr/local/bin/c++

[stevenpusser]

Since the Pale Moon packagers have said anything about dropping 32-bit support yet, I think you're still good. There's a good chance that Ubuntu 16.04 reaches end of life before that happens.

Thanks for the tips for debian/rules, though. I may have time to test them today, now that MX 19.3 is out.