Build v5.15.7

[dmik]

We updated Qt to 5.15.7 in bitwiseworks/qt5-os2#32 and this introduces (expected) build breaks in Chromium. This ticket is to address them.

bitwiseworks/qtwebengine-os2#13 is related.

[dmik]

From bitwiseworks/qt5-os2#32 (comment):

According to this commit https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=v5.15.7-lts&id=c9d902ca6ca3b1aa2e2762329d18c226d26520af Nodejs was made a requirement for Chromium 87.x. I don't know if it's actually true, I will try to hack around to disable this requirement but something tells me Chromium may indeed strictly depend on it. Though I would wonder why.

I tried to hack around the NodeJS requirement, but no success. The third_party/devtools-frontend component needs it. Making Chromium build without NodeJS was a Qt Team addition it seems. At least no have_nodejs define present in original BUILD.gn and around. Restoring this possibility to build this way seems to require quite a lot of time w/o support from the Qt Team side. It looks more prominent to port NodeJS to OS/2 instead because the amount of time looks roughly comparable and porting NodeJS instead of restoring a dropped patch is way better. First, we will have, well, NodeJS, second, it will be ways easier to upgrade to upstream in the future.

Besides that, the following parts need attention:

• third_party/abseil-cpp is now required, needs porting
• third_party/dawn/src/dawn_wire seems to be required, need porting.

The last two should be easy.

[psmedley]

Hey Dmik - did you have any luck yet with nodejs. I've done a bit of hacking of gyp, but am dying with a weird spawnvpe error:
E:/USR/BIN/make.exe -C out BUILDTYPE=Release V=1 make.exe[1]: Entering directory U:/node10/out'
touch 0efe9b907e7f462aae491c682998ecf80ee3c17f.intermediate
cd ../deps/v8/gypfiles; [ -d foo ] || mkdir -p
U:/node10/out/Release/obj/gen/torque-generated; "U:/node10/out/Release/torque" ../src/builtins/base.tq
../src/builtins/array.tq ../src/builtins/typed-array.tq -o
"U:/node10/out/Release/obj/gen/torque-generated"

make.exe[1]: spawnvpe: environment space might be exhausted
make.exe[1]: execvp: E:/usr/bin/sh.exe: Invalid argument
make.exe[1]: spawn: Invalid argument
make.exe[1]: Leaving directory U:/node10/out' make.exe: *** [node.exe] Error 2

[dmik]

Hey, I don't know for sure but it may be as it says — some environment variable (PATH?) is too long. OS/2 has a limit of 32k on the whole environment block IIRC.

[psmedley]

Yeah you were right - the make system was generating an ar comand that was over 35000 characters...

[StevenLevine]

I've proposed a gyp tweak that should work around this once we get the syntax right.

[psmedley]

FWIW I'm down to about a dozen missing symbols to get a node.exe

Assuming it does something useful, I'll setup a GitHub repo and try and fix the build system properly using Steven's suggestion to generate response files to overcome the 35k character commands gyp generates.

I'm currently building node 10, I'll probably try and move to the LTS version for git to future proof is a bit

[psmedley]

I got a node.exe this evening... of course, it's giving a SIGILL on trying to run a simple example... https://smedley.id.au/tmp/63a0afef-bc39_01-NODE-exceptq.txt has the trap. Tired this evening so will look at it tomorrow

[dmik]

Congrats! Collecting your patches in a GitHub repo is surely a good thing. I will be doing the same with my work on NodeJS too of course so that everybody could collaborate.

[psmedley]

Well hopefully we're not already duplicating efforts?

[dmik]

That would be really not very efficient. I didn't go that far so if you can publish it soon I will wait.

[psmedley]

I'll start work tonight... Getting an executable involved hacking makefiles, which is not very efficient or sustainable long term :)

[dmik]

Well, indeed, but still it may be useful as shows what needs to be tailored and where.

[StevenLevine]

Interesting exception. It appears to be by design in the generated code. It will be interesting to know why the code decided to do this. It might be the code's way of signaling a memory corruption issue.

[psmedley]

https://github.com/psmedley/node-os2 is created - I need to apply current os2 patches - I've documented the issues I remember with gyp in issues at https://github.com/psmedley/node-os2/issues

[dmik]

Cool! Will try it asap. I also have some more patches for Chromium, I will check if they are relevant.

[psmedley]

ok https://github.com/psmedley/node-os2 can now be used to generate a node.exe

See conf.cmd for some hacks that are still required to out/makefile and some directories that need to be manually created

Still generates a SIGILL on running :(

[dmik]

@psmedley BTW any particular reason why you picked up quite an old NodeJS version? 10.x seems to be really old, the last update is back from early 2020.

[psmedley]

it seemed a good idea at the time :) and it was the minimum version that qt 6.2 needed. Once things are working a bit better, I'll aim to move to node 18 - the current LTS version

FYI current node.exe is at https://smedley.id.au/tmp/node-10.19-os2-20221225.zip

I started on v18 today...

[dmik]

Well I see, I'm currently trying to build v19 with your patches so you might just hold on.

[psmedley]

V18 is mostly done https://github.com/psmedley/node-os2/tree/v18 but there is new stuff required in v8 platform-posix.cc

Meanwhile my V10 build got me a bit further on qt6webengine

[dmik]

Cool but did you fix the SIGILL problem or webengine build doesn't trigger it?

[psmedley]

Commit 5ee25ac4a7a4f108fc761924be1688b05b63abf1 hacked around the SIGILL which is a failed assertion

[dmik]

BTW, to track the NodeJS build, there is another ticket, see above.