Building fails on current master branch

[__Sandra__]

Code: Select all

# Tell the build system if we're building 64-bit.
# Set this to `BUILD_64=1` for 64-bit, leave as-is for 32-bit
BUILD_64=

# Processor architecture specific build options
if [ -n "$BUILD_64" ]; then
  BUILD_ARCH=x64
  ac_add_options --target=x86_64-pc-mingw32
  ac_add_options --host=x86_64-pc-mingw32
else
  BUILD_ARCH=x86
fi

# Automatically clobber if CLOBBER was touched
mk_add_options AUTOCLOBBER=1

# Application and target
ac_add_options --enable-application=palemoon

export MOZ_PKG_SPECIAL=avx
# export MOZ_PKG_SPECIAL=sse2

# Build options
# Adjust the -j parameter if you need more or fewer parallel build tasks
# Maximum supported without build errors is around 32
mk_add_options MOZ_MAKE_FLAGS="-j8"

ac_add_options --enable-optimize="-O2 -GTs -GS- -arch:AVX"
# ac_add_options --enable-optimize="-O2 -GTs -GS- -arch:SSE2"

# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MC_OFFICIAL=1
export MOZILLA_OFFICIAL=1

# Only enable the internal updater if you supply automatic update infrastructure
# and have configured the relevant preferences in your branding!
ac_add_options --enable-update-channel=release
ac_add_options --disable-updater

ac_add_options --disable-debug

ac_add_options --disable-precompiled-startupcache

ac_add_options --enable-jemalloc
ac_add_options --enable-strip

ac_add_options --enable-devtools

ac_add_options --disable-parental-controls
ac_add_options --disable-accessibility
ac_add_options --disable-gamepad
ac_add_options --disable-eme
ac_add_options --disable-webrtc

ac_add_options --enable-av1
ac_add_options --enable-jxl

WIN32_REDIST_DIR="C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Redist/MSVC/14.29.30133/$BUILD_ARCH/Microsoft.VC142.CRT"
WIN_UCRT_REDIST_DIR="C:/Program Files (x86)/Windows Kits/10/Redist/10.0.22000.0/ucrt/DLLs/$BUILD_ARCH"

Code: Select all

[1695311625.149, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3163): error C2039: \"Float32x4\": не является членом \"js::Scalar\"."}]
[1695311625.149, "build_output", {"line": "c:\\pm_src\\platform\\js\\src\\jsfriendapi.h(1468): note: см. объявление \"js::Scalar\""}]
[1695311625.149, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3163): error C2065: Float32x4: необъявленный идентификатор"}]
[1695311625.149, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3164): error C2039: \"Int32x4\": не является членом \"js::Scalar\"."}]
[1695311625.149, "build_output", {"line": "c:\\pm_src\\platform\\js\\src\\jsfriendapi.h(1468): note: см. объявление \"js::Scalar\""}]
[1695311625.149, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3164): error C2065: Int32x4: необъявленный идентификатор"}]
[1695311625.461, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3165): error C2039: \"Int8x16\": не явяется членом \"js::Scalar\"."}]


[1695311627.832, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3165): error C2065: Int8x16: необъявленный идентификатор"}]
[1695311627.848, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3166): error C2039: \"Int16x8\": не является членом \"js::Scalar\"."}]
[1695311627.848, "build_output", {"line": "c:\\pm_src\\platform\\js\\src\\jsfriendapi.h(1468): note: см. объявление \"js::Scalar\""}]
[1695311627.848, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3166): error C2065: Int16x8: необъявленный идентификатор"}]
[1695311627.848, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3163): error C2051: значение выражения для варианта выбора не является константой"}]
[1695311627.848, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3164): error C2051: значение выражения для варианта выбора не является константой"}]
[1695311627.848, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3165): error C2051: значение выражения для варианта выбора не является константой"}]
[1695311627.848, "build_output", {"line": "c:/pm_src/platform/js/src/wasm/WasmBaselineCompile.cpp(3166): error C2051: значение выражения для варианта выбора не является константой"}]

[Moonchild]

Clobber your objdir.

[__Sandra__]

Clobber your objdir.

I started building on a clean tree. I completely deleted "obj-i686-pc-mingw32" and other temp files.

[Moonchild]

Hmm strange, not sure how that slipped through; it built just fine for me.
Either way I'll have an update in a few. Just missed some statements in a case clause.

[__Sandra__]

[1698353007.299, "build_output", {"line": "c:/pm_src/platform/dom/base/Crypto.cpp(121): error C2429: для функция языка \"сжатое статическое утверждение\" нужен флаг компилятора \"/std:c++17\""}]

[__Sandra__]

Using the "old style" static_assert(NSID_LENGTH == 39, "error 39") instead of static_assert(NSID_LENGTH == 39); solving the problem.

[Moonchild]

Which compiler are you using, that you're running into these issues?

[athenian200]

From the output, it looks like he's using Visual Studio, but possibly an older version:

https://learn.microsoft.com/en-us/cpp/e ... w=msvc-170

The error C2429: language feature 'nested-namespace-definition' requires compiler flag '/std:c++17' is generated if you try to define a compound namespace, a namespace that contains one or more scope-nested namespace names, starting in Visual Studio 2015 Update 5. (In Visual Studio 2017 version 15.3, the /std:c++latest switch is required.) Compound namespace definitions are not allowed in C++ prior to C++17. The compiler supports compound namespace definitions when the /std:c++17 compiler option is specified:

[Moonchild]

We don't really support older versions of MSVC. It's assumed that when building on windows, people are using MSVC2022 community or Pro/Enterprise. That said, static_assert() with a single argument is c++17 or later and I've adapted it for the time being; c++17 language standard is slated for the next cycle though, and older MSVC may no longer be sufficient to even build at that point.

[dbsoft]

https://repo.palemoon.org/dbsoft/UXP/co ... e038c2d427

I had to do this to get it building with VS2017.

Seems to work fine for me once making those changes, I was about to ask if you wanted patches to allow building with older versions. I have computers or partitions with Windows with different versions of compilers and OSes to test with from time to time.

https://dbsoft.org/Screenshots/VS2017.png

[Moonchild]

I was about to ask if you wanted patches to allow building with older versions.

No; the whole point of moving to VS2022 is that we could move forward with later C++ language standards.
I skipped from VS2015 to VS2022 to avoid specific compiler conformance issues in VS2017 and 2019, in fact. I looked at VS2017 briefly and found it needed a whole lot more than what your code changes shown there are for correct operation (beyond being able to build).
I do not think it's wise to patch our tree for buildability on a version we've never supported to begin with that does not provide a proper foundation going forward.

[dbsoft]

No; the whole point of moving to VS2022 is that we could move forward with later C++ language standards.

Alright, well I'll keep patching it in my own tree for my own purposes. I am not sure what you are seeing that wouldn't be supported by VS2017. From my research it should support most of C++17. (VS2017 is probably the oldest version we should be able to support going forward, but I completely understand not wanting the patches for it).

[__Sandra__]

Which compiler are you using, that you're running into these issues?

I use MSVS 2019 with the latest updates. I'm building a project on win7.

[athenian200]

I had to do this to get it building with VS2017.

What I'm curious about is, did you try that /std:c++17 compiler flag the error suggested? Like, I'm wondering if adding that flag into the build configuration for that part of the code would make that error go away?

I don't think patching to support older C++ standards is a great idea (as MC said, we adopted newer MSVC precisely not to be hamstrung by missing support for newer C++ standards), but I think using switches to coerce older MSVC into recognizing certain codepaths as C++17 isn't a big deal. It would just be a "use at your own risk" thing at that point, because obviously that won't be tested as much going forwards.

[dbsoft]

What I'm curious about is, did you try that /std:c++17 compiler flag the error suggested? Like, I'm wondering if adding that flag into the build configuration for that part of the code would make that error go away?

I suspect it would with the static_assert() but the namespace issues, I am not sure what is causing those.

[Moonchild]

the namespace issues, I am not sure what is causing those.

As far as I understand that is particularly part of the problem targeting VS2017/VS2019 as namespace handling changed between them (and in the standard too, so maybe their initial change implementation wasn't correct? or maybe the spec changed from under them... )

[athenian200]

Off-topic:
Just have to say, it looks like we really dodged a bullet skipping to VS2022, because neither GCC nor Clang have these sorts of issues. VS2017 and VS2019 appear to have been terrible versions of MSVC and VS2022 is now making a serious effort to comply with the standards and be more compatible with modern C++.

[Moonchild]

Off-topic:
I initially looked at going through 2017 and 2019 like Mozilla, but I saw there was a lot of hackery going on especially for 2017 that was undone again later on... so...

[dbsoft]

As far as I understand that is particularly part of the problem targeting VS2017/VS2019 as namespace handling changed between them (and in the standard too, so maybe their initial change implementation wasn't correct? or maybe the spec changed from under them... )

Well if it was a spec change I would expect other compilers of a similar vintage to have the same issues, and this is the only one I see this with, but who knows. I agree 2022 is a vast improvement, but they have slowly been improving 2017, and at this point it seems suited to building a stable Pale Moon/UXP with minor modifications.

Off-topic:
Just to explain my situation and why I use it, I have a number of computers with Windows and for testing purposes I have a different MSVC version on each one. I have an older PC with Windows 10 and VS2017 installed which is the only Windows machine that can be accessed remotely. The rest are all firewalled (or on Intel Macs that are normally running MacOS). So if I ever need to test a Windows build when not at home, that is the one I can access remotely and it has 2017 on it It is also important that the 2017 one be the remotely accessible one, because I have a project that requires 2017. It won't build on newer versions, so until that project migrates to a newer MSVC, it is important that I have that build system accessible.

[__Sandra__]

On my configuration with new C++17 settings, it compiles well. The sizes of the files are larger

filesize.png