Building fails on current master branch

Discussions about the development and maturation of the platform code (UXP).
Warning: may contain highly-technical topics.

Moderators: trava90, athenian200

User avatar
__Sandra__
Moonbather
Moonbather
Posts: 55
Joined: 2022-05-16, 08:00
Location: Chernihiv, Ukraine

Building fails on current master branch

Post by __Sandra__ » 2026-05-19, 11:21

Code: Select all

...
 1:09.03 Creating config.status
 1:09.03 Inserting coin...
 1:09.70 Traceback (most recent call last):
 1:09.70   File "c:/pm_src/configure.py", line 47, in <module>
 1:09.70     sys.exit(main(sys.argv))
 1:09.70   File "c:/pm_src/configure.py", line 44, in main
 1:09.70     return config_status(config)
 1:09.70   File "c:\pm_src\platform\configure.py", line 97, in config_status
 1:09.70     return config_status(args=[], **sanitized_config)
 1:09.70   File "c:\pm_src\platform\python\mozbuild\mozbuild\config_status.py",
line 149, in config_status
 1:09.70     definitions = list(definitions)
 1:09.70   File "c:\pm_src\platform\python\mozbuild\mozbuild\frontend\emitter.py
", line 175, in emit
 1:09.72     objs = list(self.emit_from_context(out))
 1:09.72   File "c:\pm_src\platform\python\mozbuild\mozbuild\frontend\emitter.py
", line 1008, in emit_from_context
 1:09.72     raise SandboxValidationError('nasm 2.14 or later is not available',
 context)
 1:09.72 mozbuild.frontend.reader.SandboxValidationError:
 1:09.72 ==============================
 1:09.72 ERROR PROCESSING MOZBUILD FILE
 1:09.72 ==============================
 1:09.72
 1:09.72 The error occurred while processing the following file or one of the fi
les it includes:
 1:09.72
 1:09.72     c:/pm_src/platform/media/libdav1d/x86/moz.build
 1:09.72
 1:09.72 The error occurred when validating the result of the execution. The rep
orted error is:
 1:09.72
 1:09.72     nasm 2.14 or later is not available
 1:09.72
 1:09.72
 1:09.81 *** Fix above errors and then restart with\
 1:09.81                "c:/mozilla-build/bin/mozmake.EXE -f client.mk build"
 1:09.81 mozmake.EXE: *** [client.mk;370: configure] Error 1

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 1940
Joined: 2018-10-28, 19:56
Location: Georgia

Re: Building fails on current master branch

Post by athenian200 » 2026-05-19, 11:28

This is a known issue, and it's a result of a new library added to the tree that requires NASM:

https://repo.palemoon.org/MoonchildProd ... /UXP-build

It may also be possible to build by adding --disable-av1 to your .mozconfig.
"Linux makes everything difficult." -- Lyceus Anubite
"Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works." -- Steve Ballmer
"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in ten." -- Bill Gates

User avatar
Moonchild
Project founder
Project founder
Posts: 39727
Joined: 2011-08-28, 17:27
Location: Sweden

Re: Building fails on current master branch

Post by Moonchild » 2026-05-19, 11:42

Please note updated build instructions on https://developer.palemoon.org/build/windows/
"Sales hates anything that can't be turned into a confident sentence." - anonymous warehouse worker
"Why debate someone you fundamentally don't trust?" - Dario Amodei
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
__Sandra__
Moonbather
Moonbather
Posts: 55
Joined: 2022-05-16, 08:00
Location: Chernihiv, Ukraine

Re: Building fails on current master branch

Post by __Sandra__ » 2026-05-20, 10:57

Thanks for the tip. After adding "nasm.exe", the configuration was successful and the build process began.

But another problem appeared. I'm trying to build a 32-bit version on a 64-bit host system. During the build process, the process of linking file "gkmedias.dll" seems to freeze. There are no error messages, the build just stops. CPU load is about 0.

User avatar
Moonchild
Project founder
Project founder
Posts: 39727
Joined: 2011-08-28, 17:27
Location: Sweden

Re: Building fails on current master branch

Post by Moonchild » 2026-05-20, 11:35

Did you follow the instructions for building 32 bit ?
I.e. using the older c compiler and linker.
"Sales hates anything that can't be turned into a confident sentence." - anonymous warehouse worker
"Why debate someone you fundamentally don't trust?" - Dario Amodei
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

q160765803
Moon lover
Moon lover
Posts: 96
Joined: 2023-04-13, 07:57

Re: Building fails on current master branch

Post by q160765803 » 2026-05-20, 12:20

__Sandra__ wrote:
2026-05-20, 10:57
Thanks for the tip. After adding "nasm.exe", the configuration was successful and the build process began.

But another problem appeared. I'm trying to build a 32-bit version on a 64-bit host system. During the build process, the process of linking file "gkmedias.dll" seems to freeze. There are no error messages, the build just stops. CPU load is about 0.
I think MS Linker refused to place AVX instructions in 32bit binary,
Downstream seems fixed this issue: https://github.com/roytam1/UXP/commit/8 ... 09d2703ae3

User avatar
__Sandra__
Moonbather
Moonbather
Posts: 55
Joined: 2022-05-16, 08:00
Location: Chernihiv, Ukraine

Re: Building fails on current master branch

Post by __Sandra__ » 2026-05-20, 13:19

Yes, I am building a 32-bit version with the -arch:AVX switch, but before updating the AV1 library there were no problems with the building.

User avatar
__Sandra__
Moonbather
Moonbather
Posts: 55
Joined: 2022-05-16, 08:00
Location: Chernihiv, Ukraine

Re: Building fails on current master branch

Post by __Sandra__ » 2026-05-21, 09:31

q160765803 wrote:
2026-05-20, 12:20
I think MS Linker refused to place AVX instructions in 32bit binary,
Downstream seems fixed this issue: https://github.com/roytam1/UXP/commit/8 ... 09d2703ae3
Thanks for the tip.

I finally managed to assemble the project completely.

To do this, I removed references to files with AVX2 and AVX512 from “/media/libdav1d/x86/moz.build”. It seems that the linker has a problem with linking newer (than just AVX) instructions for the 32-bit platform. The build stopped with a linking error due to the missing code "smooth_weights_1d_16bpc" and "smooth_weights_2d_16bpc". After adding the appropriate functions to the file "ipred16_sse.asm" as done in the commit above, the build completed successfully.

User avatar
Moonchild
Project founder
Project founder
Posts: 39727
Joined: 2011-08-28, 17:27
Location: Sweden

Re: Building fails on current master branch

Post by Moonchild » 2026-05-21, 11:42

__Sandra__ wrote:
2026-05-20, 13:19
Yes, I am building a 32-bit version with the -arch:AVX switch, but before updating the AV1 library there were no problems with the building.
Yes, this seems to be an issue with the linker not being able to handle assembled AVX/AVX2 in the way Dav1d defines.
Not including AVX on non-AVX targets is the smart thing anyway.
I don't agree with the way it was done by RT1 though, so I've adopted it in a slightly different way.

As an aside: -arch:AVX does nothing on 32-bit, as AVX is an exclusively 64-bit CPU instruction set.
"Sales hates anything that can't be turned into a confident sentence." - anonymous warehouse worker
"Why debate someone you fundamentally don't trust?" - Dario Amodei
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Moonchild
Project founder
Project founder
Posts: 39727
Joined: 2011-08-28, 17:27
Location: Sweden

Re: Building fails on current master branch

Post by Moonchild » 2026-05-21, 11:45

Pull request: https://repo.palemoon.org/MoonchildProd ... pulls/3100

This should fix 32-bit building of Dav1d.
I think the "external" inclusion of the smoothing weights functions/data in sse across from the avx2 source was an error and upstream should probably fix this.
"Sales hates anything that can't be turned into a confident sentence." - anonymous warehouse worker
"Why debate someone you fundamentally don't trust?" - Dario Amodei
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
__Sandra__
Moonbather
Moonbather
Posts: 55
Joined: 2022-05-16, 08:00
Location: Chernihiv, Ukraine

Re: Building fails on current master branch

Post by __Sandra__ » 2026-05-22, 07:58

Moonchild wrote:
2026-05-21, 11:42
As an aside: -arch:AVX does nothing on 32-bit, as AVX is an exclusively 64-bit CPU instruction set.
I don't agree with this statement.

I disassembled the files built with -arch:AVX and -arch:SSE2 key.They are different and in the files compiled with key -arch:AVX there are AVX instructions. Here is an example, even the palemoon.exe file itself contains AVX processor instructions.
instr.png
In more complex files, for example gkmedias.dll, the code difference is even more significant.
instr2.png
You do not have the required permissions to view the files attached to this post.

User avatar
Moonchild
Project founder
Project founder
Posts: 39727
Joined: 2011-08-28, 17:27
Location: Sweden

Re: Building fails on current master branch

Post by Moonchild » 2026-05-22, 09:29

That's news to me.

Seems Microsoft added AVX across the board to their compilers even for 32-bit targets which makes no sense to me (outside of just unifying compiler internals) as there are no 32-bit processors that support AVX, to my knowledge, since they were introduced in Sandy Bridge (Intel) and Bulldozer (AMD). Previously, it was also clear that this did nothing/should not do anything as the 32-bit targeting CL of MSVC did not offer -arch:AVX as a compile option.
So, building with -arch:AVX (or later) on a 32-bit target assumes you are not building true 32-bit binaries. I don't know why that would be desirable over 64-bit native.
"Sales hates anything that can't be turned into a confident sentence." - anonymous warehouse worker
"Why debate someone you fundamentally don't trust?" - Dario Amodei
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 1940
Joined: 2018-10-28, 19:56
Location: Georgia

Re: Building fails on current master branch

Post by athenian200 » 2026-05-22, 09:56

Well, it's worth bearing in mind that there was a fairly long period where we had mostly 32-bit binaries running on 64-bit CPUs. A lot of applications for the longest time only provided 32-bit x86 versions of themselves even if they were expected to run on 64-bit machines. So in some cases, supporting newer CPU instructions while still compiling a 32-bit binary would have possibly made sense for people targeting a newer CPU who hadn't bothered to write an application in such a way that it could be compiled as 64-bit to start with, maybe too dependent on 32-bit assumptions, but still wanted to take advantage of AVX.

Not saying this was a super common edge case, but I do recall there were a lot of applications that took forever to start providing a 64-bit version, or which would still push the 32-bit version as default because of various incompatibilities introduced by 64-bit, and that this was going on (less and less admittedly) until probably at least 2014 or so. AVX would likely be among the last new instruction sets to be introduced while people were still in the weird "32-bit binaries, 64-bit CPU" transitional mindset. I seem to recall vaguely that weird period persisted a lot longer on older 64-bit architectures where RAM was at a premium, like on Solaris SPARC for instance. Linux is the odd one out here, it generally expected most of the binaries to be 64-bit if you were running 64-bit Linux, or 32-bit if you were running 32-bit Linux. There were 32-bit compatibility libraries for third-party binaries for a while, but they were not recommended and distros tended to avoid using that in their repos where possible.

I remember this precisely because I didn't want to buy a 64-bit CPU that would "go to waste" if all the applications were still 32-bit for a long time. If I didn't have enough RAM to make use of additional address space or 64-bit applications, it seemed a bit pointless until the late 2000s when I started seeing enough 64-bit applications to not feel like a 64-bit machine was a waste.
"Linux makes everything difficult." -- Lyceus Anubite
"Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works." -- Steve Ballmer
"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in ten." -- Bill Gates

User avatar
Moonchild
Project founder
Project founder
Posts: 39727
Joined: 2011-08-28, 17:27
Location: Sweden

Re: Building fails on current master branch

Post by Moonchild » 2026-05-22, 10:55

But we're in 2026 now. 2014 was a long time ago.
"Sales hates anything that can't be turned into a confident sentence." - anonymous warehouse worker
"Why debate someone you fundamentally don't trust?" - Dario Amodei
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 1940
Joined: 2018-10-28, 19:56
Location: Georgia

Re: Building fails on current master branch

Post by athenian200 » 2026-05-22, 14:21

Moonchild wrote:
2026-05-22, 10:55
But we're in 2026 now. 2014 was a long time ago.
Oh, I agree. I just meant MSVC never dropped that from their 32-bit build path, and just left it in until 32-bit builds were dropped. We are indeed in 2026... that's why Windows 11 doesn't have a 32-bit version, and later MSVC toolchains than the one we are on can't produce 32-bit binaries at all. We're using the very last version that has the ability to do that.
"Linux makes everything difficult." -- Lyceus Anubite
"Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works." -- Steve Ballmer
"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in ten." -- Bill Gates

User avatar
__Sandra__
Moonbather
Moonbather
Posts: 55
Joined: 2022-05-16, 08:00
Location: Chernihiv, Ukraine

Re: Building fails on current master branch

Post by __Sandra__ » 2026-05-25, 06:46

Moonchild wrote:
2026-05-22, 09:29
So, building with -arch:AVX (or later) on a 32-bit target assumes you are not building true 32-bit binaries. I don't know why that would be desirable over 64-bit native.
It looks like things are even more complicated.

The SSE2 command extension appeared in the Intel Pentium 4 processor along with the EM64T. Therefore, the code that is compiled with the -arch:SSE2 key is no longer an ordinary 32-bit code. If you need a real i386, then there is key -arch:IA32. At the moment, I think there are no more systems left that do not support SSE2. The only question is AVX. Unfortunately, most “simple” even new processors do not support it.

User avatar
jobbautista9
Board Warrior
Board Warrior
Posts: 1251
Joined: 2020-11-03, 06:47
Location: Philippines

Re: Building fails on current master branch

Post by jobbautista9 » 2026-05-25, 08:46

We don't and have never targeted the 386. The very first published Pale Moon version (and that was 32-bit only) had a minimum target of Pentium III, when SSE was the SIMD instruction set being optimized against.
Image

Tired of creating stuff!

Avatar artwork by Shinki669: https://www.pixiv.net/artworks/113645617

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.