A bunch of failures with nodejs on the builders
ryandesign at macports.org
Mon May 2 11:57:31 UTC 2022
On Apr 25, 2022, at 07:54, David Gilman wrote:
> There were a handful of pushes of new nodejs versions (at least nodejs
> 18 through 15) in the past week and a bunch of binary builders failed.
> Some of these look ephemeral and just need xcode reinstalled or
> whatever. I'd appreciate it if the admins could do that. There is also
> an exotic hard build failure.
> On 10.6 and macOS 11 the build ran out of disk space.
I don't know if you meant 10.6 x86_64 or 10.6 i386. At the moment, 10.6 x86_64 has 66.7 GB available and 10.6 i386 has 68.7 GB available. I cannot conceive of a build that could take that much space so I would not believe an "out of disk space" message here.
nodejs15, 16, 17, 18 are marked as "known fail" on OS X 10.8 and earlier, therefore the build system will not attempt to build them on those OS versions. If you were looking at build status information on ports.macports.org, it would be from the last time the build was attempted before "known fail" was added to them (and "known fail" was presumably added to them because nobody wanted to figure out how to fix whatever the problem was).
I looked at build logs for nodejs13 and some older nodejs versions from 10.6 and it was complaining about the version of python. You could file bug reports in the issue tracker to get those ports fixed to use the right python, or whatever the problem is.
You didn't say whether 11 x86_64 or 11 arm64 but looking at the logs I assume 11 x86_64:
fatal error: /Library/Developer/CommandLineTools/usr/bin/libtool: can't write to output file (No space left on device)
At the moment, 11 x86_64 has 20.2 GB available. This might not be enough to build the largest ports especially if the build is memory intensive and some of the space gets used for swap. In addition, as you may know, a bug in recent macOS causes it to download the 12+ GB macOS Monterey installer periodically which would have left it with only 8 GB available. Looks like the automatic Monterey installer download happened most recently on 4/18 and that build failure log is from 4/20. I did already remove the installer but I guess it wasn't until after 4/20 since the log shows that after cleanup only 8 GB was available:
So retrying the builds now should succeed. I've triggered builds of any unbuilt nodejs ports on 11 x86_64 (which turned out to be only nodejs18):
The build succeeded.
11 arm64 had 25.2 GB available. I deleted the unrequested Monterey installer and now it has 38.7 GB free.
> On 10.15 there were missing xcode installation related errors.
All builders have of course always had Xcode and the Xcode command line tools installed. However, as you may know, a bug in recent macOS causes it to delete the CLT installation receipt at some point:
The MacPorts cltversion portgroup and apparently some parts of the nodejs build use to determine information about the CLT. The conditions which cause the CLT receipt to be deleted are not known. Performing software updates may be one of the conditions. I checked and indeed the 10.15 builder's CLT receipt has once again disappeared, so I have once again reinstalled the CLT to put it back and scheduled new builds of any unbuilt nodejs ports on 10.15 (which turned out to be nodejs17 and nodejs18):
As of now, the nodejs17 build just completed successfully and the nodejs18 build is beginning.
> On 10.7, 10.8 and 10.9 linking failed while linking
> Undefined symbols for architecture x86_64:
> "_macports_legacy_sysconf", referenced from:
> v8::base::OS::AllocatePageSize() in libv8_libbase.a(platform-posix.o)
> v8::base::OS::Allocate(void*, unsigned long, unsigned long,
> v8::base::OS::MemoryPermission) in libv8_libbase.a(platform-posix.o)
You're right, nodejs10 does have that build failure on 10.7, 10.8, 10.9, and 10.6 as well. Sounds like a defect either in our legacy support or in the way this port is using it. Please file a ticket in the issue tracker. I don't see "-lMacportsLegacySupport" among the flags being given to the compiler, which is probably necessary to fix this. This flag is already in LDFLAGS but the build system may be ignoring it.
More information about the macports-dev