Building Pale Moon for WinXP, SSE CPU

[Mercury]

Sorry if this isn't the right subforum; it seemed the most appropriate.

The short and sweet: I'm trying to compile Pale Moon to work on an old PC, under Windows XP (32-bit), running on an Athlon XP CPU (SSE only; no SSE2).

I have reasons for keeping this machine alive as long as I can. As I've failed in my attempts to build Pale Moon that would work on it, I've been using Firefox 24ESR - which works quite well. Since this version of FIrefox is out of support, however, I'd like to give Pale Moon another go, this time with the source code from here

Unfortunately the same problem I've seen before occurs with the latest version. The compiled product runs fine on the build machine, but on the target machine, an error in softokn3.dll on startup: https://forum.palemoon.org/viewtopic.php?f=5&t=3328&start=10#p25000

What should my next steps be, if I want to figure out why this error is happening?

[access2godzilla]

I know this is not an answer to your question, but have you looked at the list of contributed builds to see if the SSE build works for you?

Compiling your own programs is fun, though. I'll have a go at this, but then again, setting up the environment happens to be a PITA on Windows.

[Mercury]

I think I got it!

I had a sneaking suspicion that the "-arch:SSE" compiler option wasn't being properly propagated when it was only included in .mozconfig as part of "--enable-optimize". Perhaps something at a deeper level of the build system was ignoring that option, when building specific DLLs... or something. I'm really not sure; someone more familiar with the codebase/build system might shed some light.

Anyway, based on that suspicion, I added "-arch:SSE" to the CL environment variable, so the option would always be applied unless explicitly overridden.

It's a bit early, as I've only used the resulting binary for about 3 minutes, and I turned off a lot of the optimizations in .mozconfig during my experiments, but it certainly looks like I have Pale Moon running on the target system!

BTW, access2godzilla, the SSE contributed build is at version 24.6.2, so too old for my tastes.

[Moonchild]

Using --enable-optimize={flags} does pretty much the same thing as manually adding it to CL; you shouldn't need to use anything besides the .mozconfig option.

It may be possible that you're using a system-installed .dll - did you package the browser before copying it to the target machine with ./mach package or did you just copy dist/bin across?

EDIT: It's possible that optimization flags get cleared in some parts of the Mozilla build system instead of just filtering out what shouldn't be used or overriding flags by appending desired ones (as is done everywhere else in the tree), ending up with always using compiler defaults for the sub-tree.
That's just really poor programming on Mozilla's side of things; I'll have a look into this.

EDIT2: Seems it's exactly what happens. How CFLAGS is passed down the tree is rather convoluted in terms of what is done with it, though. NSS inherits them from NSPR, which has its own sub-configure, and there's several related variables that get used (including copying flags to and from temporary _SAVE variables and the likes). I'd have to fully analyze how variables are passed down to solve this in-tree. Not really something I want to do when there's already a way around it

You should consider it a quirk for building for SSE that you have to set the /arch:SSE flag at the top level when using VS2012. Welcome to the world of Mozilla!

[Mercury]

I just wish I'd known this months ago. Could've been running PM on that machine this whole time. I know I'm really pushing it, what with the out-of-support OS, but for hardware a decade old, it all still works beautifully, and I know XP so well by now that I have everything working exactly the way I want.

(Not that I'm blaming you for not knowing... I can only imagine keeping track of a project this large leaves limited think time for hobby edge cases like mine.)

Anyway, I just want to report that I successfully built PM 25.0.2 with all the optimizations that seemed appropriate, and it works well so far! Now I just have to rely on Tobin to keep the PM4XP source up to date...

[Chris486]

I thought I'd bump this thread to let folks know I was also able to succesfully compile Pale Moon for an SSE computer. (Thanks in part to some gracious help from Moonchild.)

The build environment was a P3 (same as the target machines), XP SP3, & Visual C++ 2010 SP1.

I used the PM4XP32 25.1 source and the following .mozconfig

Code: Select all

ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-O2 -arch:SSE"
ac_add_options --enable-jemalloc
ac_add_options --disable-crashreporter
ac_add_options --disable-accessibility
ac_add_options --disable-parental-controls
ac_add_options --disable-maintenance-service
ac_add_options --disable-webrtc
ac_add_options --disable-metro
ac_add_options --disable-gamepad
ac_add_options --disable-webgl
ac_add_options --disable-necko-wifi

It appears Mercury's problem with the SSE flag may be specific to VS2012. I had no issues with that in 2010.

The build took just over 10 hours, but it works. It's amazing how smooth the modern web can still be on these old machines (given enough RAM).

After I did the above I went ahead and compiled firefox 31.3 ESR with a similar set of flags and compared the two. With a similar set of plug-ins (CTR in FF being the exception), Pale Moon uses ~52MB less RAM at idle and around 17% better in the SunSpider JS benchmark.

I can't complain.

[Moonchild]

The SSE issue is indeed related to VS2012, since VS2012 uses SSE2 architecture by default (and you have to override it with /arch:IA32). You could optimize further by using the same CL trick (since the otherwise problematic parts are now compiled in i386 mode and won't use SSE) but it'll probably not make a practical difference.

[New Tobin Paradigm]

You don't HAVE to build on period hardware. Just install 2010 on any modern machine and compile the same way. Will take like 70-140 min then instead of TEN HOURS.

[Chris486]

You don't HAVE to build on period hardware. Just install 2010 on any modern machine and compile the same way. Will take like 70-140 min then instead of TEN HOURS.

I had read somewhere that there's a performance benefit to compiling on the target machine. This could be wrong, but I figured why not as I wanted to see if it would work anyway.

The SSE issue is indeed related to VS2012, since VS2012 uses SSE2 architecture by default (and you have to override it with /arch:IA32). You could optimize further by using the same CL trick (since the otherwise problematic parts are now compiled in i386 mode and won't use SSE) but it'll probably not make a practical difference.

Thanks I wasn't aware of that. I'll change that when the time to build the next update comes .

Incidentally, the MSDN docs say i386/486 target support was removed in VS5.0. I wasn't aware VS still had the ability to spit out generic i386 code as a fallback, so that's good to know. (This is all a learning process for me. )

[Moonchild]

It's probably i586 code, actually In any case 32-bit Intel Architecture (generic x87 fp etc), without SIMD extensions. I don't think it'll actually be all the way backwards compatible with 386.

[jangdonggun1234]

I know this question a little bit off-topic, but is there any advantage of SSE, SEE2 over vanila build ? I know that people said SSE and SSE2 speed up something, but it really work on web browser ? Problem is that it also limit CPU of user, user cannot use old CPU to run SSE or SSE2 application, so I think maybe we just need to build Palemoon like Firefox vanila instead SSE2 ?

[Moonchild]

SSE and SSE2 are important for faster handling of many things. The instruction sets add much faster routines for many operations, and making use of them is important to provide a speedy browser.

SSE2 has been standard in any CPU since 2001 (or a little later for AMD since they used 3DNow! instead of the Intel SIMD instructions initially). Even the AthlonXP, no matter how popular, is really old and obsolete by now in the grand scheme of things.
Catering to that kind of museum-grade hardware is not part of Pale Moon's intended use for any builds. Of course you can build your own if needed, but that'll be the extent of it.

[Chris486]

I went ahead and built the 25.2 update (is it still an 'update' when you build it from scratch? heh) and noticed something interesting.

I'm not sure if this has relevancy to a "modern" build of the mainline version but I thought I'd note it -

Using the latest mozilla-build which was updated at the end of the December (1.11) produces numerous errors when you run ./mach build. Reverting to 1.10 builds successfully. Looking at the changenotesf or 1.11, there is this:

* Updated Python to version 2.7.8. This was previously blocked on the EOL
of esr24. While version 2.7.9 has been released, we aren't comfortable
taking it at this time due to the large-scale changes backported to it.

I'm not sure if that's the cause of the error or if one of the other changes is, but 1.11 doesn't work and 1.10 does. In any event, 25.2 seems solid .

[Moonchild]

You indeed shouldn't be using the latest MozillaBuild if they updated python in it since it has breaking changes. I'll have to remember to add this to the build docs next time I get around to it.

[New Tobin Paradigm]

The MozillaBuild package of tools you should be using is 1.8 located uhh... here: https://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-1.8.0.exe

[Moonchild]

Actually, if you're using the howto, you should be using 1.10 -- I've updated the post to link directly to it. Otherwise, the names of the batch files won't match

I myself am using 1.8.0 because I've adapted a number of tools in it and I don't see an advantage to throw that work away. So, "official" distributions will be built with 1.8.0 (for now, anyway)

[jangdonggun1234]

Hi Chris486,
Can you share your XP build ? I'm have a XP computer that isn't support SSE2, so I really want to use Palemoon 25.2.0 instead Firefox on that low-end computer.

[Chris486]

Hi Chris486,
Can you share your XP build ? I'm have a XP computer that isn't support SSE2, so I really want to use Palemoon 25.2.0 instead Firefox on that low-end computer.

Hi jangdonggun1234,

I just saw this and if you are still around, I do indeed have versions 25.2, 25.3, 25.4.1, and a frankenbuild of 25.5 (described below). However, all but one were compiled with --enable-official-branding to get the full moon experience and I'm not sure what the rules or etiquette is on distributing that. That aside, I'm happy to send you the binaries.

I've been building Pale Moon as initially described since earlier in this thread. Building 25.5 appears to have issues with the updated libcubeb library. I verified that both the pm4xp32 and 25.5_AtomRelease display the same error, which is shown below:



It is followed by this output, complaining of missing libraries:

Code: Select all

conftest.c
configure(27092) : warning C4013: 'posix_fallocate' undefined; assuming extern returning int
kernel32.lib
c1 : fatal error C1083: Cannot open source file: 'kernel32.lib': No such file or directory
user32.lib
c1 : fatal error C1083: Cannot open source file: 'user32.lib': No such file or directory
gdi32.lib
c1 : fatal error C1083: Cannot open source file: 'gdi32.lib': No such file or directory
winmm.lib
c1 : fatal error C1083: Cannot open source file: 'winmm.lib': No such file or directory
wsock32.lib
c1 : fatal error C1083: Cannot open source file: 'wsock32.lib': No such file or directory
advapi32.lib
c1 : fatal error C1083: Cannot open source file: 'advapi32.lib': No such file or directory
secur32.lib
c1 : fatal error C1083: Cannot open source file: 'secur32.lib': No such file or directory
netapi32.lib
c1 : fatal error C1083: Cannot open source file: 'netapi32.lib': No such file or directory
Generating Code...
configure: failed program was:
#line 27088 "configure"
#include "confdefs.h"
#define _XOPEN_SOURCE 600
  #include <fcntl.h>
int main() {
posix_fallocate(0, 0, 0);
; return 0; }

Of course, the libraries are indeed present and I went back and verified that 25.4 builds succesfully still, which it does. It does appear the mozbuild file has changed between the two versions. Backing libcubeb to the 25.4 source allowed 25.5 to build with no other apparent issues.

[Moonchild]

2 quick responses here:

Distribution of officially-branded binaries is subject to the redistribution license, which in short means: you can't publicly distribute these without clearing it with me first. Of course you can send them privately to friends or acquaintances if you so wish
If you are planning to maintain legacy builds and wish to publish them, get in touch with me. We obviously cannot provide support for these rebuilds though so if it's an issue for users they might come knocking on your door

The libcubeb issue is solved by adding --disable-tests to your .mozconfig. This is caused by using the update from a Mozilla which includes incompatible build system commands in the tests for it. This will be addressed in the next version's source archive.

[New Tobin Paradigm]

It looks like this is being built off the BinOC Repository on github. Do know that repo won't be updated forever. PM4XP ends July 14th when the last retail available version of NT 5.x end of lifes (Server 2003).

Also the PM4XP branches != the Atom branch which can also produce XP compatible versions but with settings for low-power atom machines so if you plan to do this for real you will have to make some forward thinking decisions. I would be willing to give you a hand in the procedures I have used.