Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v22.0.0 build failed #141

Closed
nschonni opened this issue Apr 24, 2024 · 19 comments
Closed

v22.0.0 build failed #141

nschonni opened this issue Apr 24, 2024 · 19 comments

Comments

@nschonni
Copy link
Member

I think it ran the x86 build, then crashed out if I'm reading the logs right https://unofficial-builds.nodejs.org/logs/202404241830-v22.0.0/build.log

@LaurentGoderre
Copy link
Member

Yeah, here is the x86 logs and its definitely failing: https://unofficial-builds.nodejs.org/logs/202404241830-v22.0.0/x86.log

@richardlau
Copy link
Member

x86 looks broken and someone will need to look at it. Maybe the container and/or compiler will need to be updated, or there might be a real issue with x86 in V8.

I've requeued the remaining recipes:

./bin/queue-push.sh -v v20.0.0 -r musl -r x64-glibc-217 -r armv6l -r loong64 -r riscv64 -r x64-pointer-compression -r x64-debug

(FYI I'm not going to be around to babysit these through.)

@nschonni
Copy link
Member Author

Thanks @richardlau! I'll keep on eye on https://unofficial-builds.nodejs.org/logs/202404242126-v20.0.0/ and see if it works out

@nschonni
Copy link
Member Author

Oh, @richardlau I'm now seeing that you requeued v20 rather than v22. Not sure if that's going to cause an issue with the old images if the SHAs get updated for that old release

@richardlau
Copy link
Member

erk. Good catch. I've killed off the running processes/queued stuff and requeued for 22:

$ ./bin/queue-push.sh -v v22.0.0 -r musl -r x64-glibc-217 -r armv6l -r loong64 -r riscv64 -r x64-pointer-compression -r x64-debug
Queuing v22.0.0 with recipes: musl,x64-glibc-217,armv6l,loong64,riscv64,x64-pointer-compression,x64-debug
$

@richardlau
Copy link
Member

@targos
Copy link
Member

targos commented Apr 25, 2024

armv6l uses a too old GCC

@nschonni
Copy link
Member Author

Although there may be architectures that are still failing, I'm going to close this one since the main issue of the build filing is addressed. If there are specific architecture issues that are going to persist in v22, it's probably good to spin up issues and disable them until they can be addressed

@LaurentGoderre
Copy link
Member

Isn't this going to be the case for the next v22 release though? should the x86 build be moved down the list to prevent this happening again?

@rvagg
Copy link
Member

rvagg commented Apr 29, 2024

https://github.com/nodejs/unofficial-builds/blob/main/recipes/armv6l/should-build.sh this should be fixed to stop it building >= 22, does someone here want to give that a go?

then, if someone wants to make this work again, they can put in the work to get the compiler upgraded, but as of today, it'd be on me and I'm very unlikely to do this any time soon

@rvagg rvagg reopened this Apr 29, 2024
@LaurentGoderre
Copy link
Member

@rvagg yep! On it!

@LaurentGoderre
Copy link
Member

#142

@DanielSchuech
Copy link

DanielSchuech commented Apr 29, 2024

armv6l uses a too old GCC

shouldn't armv6l be disabled instead of x86? @LaurentGoderre

@LaurentGoderre
Copy link
Member

@DanielSchuech the primary issue at this point is preventing the failing x86 from interfering with the next v22 release. I believe @rvagg was sending that file as an example on how to control the build.

@richardlau
Copy link
Member

richardlau commented Apr 29, 2024

Both x86 and armv6l builds failed for Node.js 22.0.0.

@nschonni
Copy link
Member Author

Opened #143 for the armv6l by copying the other PR

@DanielSchuech
Copy link

Thanks for the explanation. I only had a look into the latest log folder where no x86.log was present.

@richardlau
Copy link
Member

Thanks for the explanation. I only had a look into the latest log folder where no x86.log was present.

Yes, because I didn't queue x86 since it failed in the original attempt.

@rvagg
Copy link
Member

rvagg commented Apr 29, 2024

thanks for the two should-run changes @LaurentGoderre & @nschonni

If anyone wants to tackle armv6l, the path I'd take is to just produce a new https://github.com/rvagg/rpi-newer-crosstools with a the minimum compiler and libc needed to support node. It looks like there's newer crosstools-ng that support up to gcc 13 so it shouldn't be too hard. I think I explain the process in that repo about taking an existing config and running a newer crosstools-ng and picking new versions.

@rvagg rvagg closed this as completed Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants