cmake, cmake-devel: Update to 3.27.2

[ryandesign (Ryan Carsten Schmidt)]

The cmake port is at version 3.24.4 and cmake-devel is at 20230308-3.26.0-rc6-454bfa77. cmake 3.26.4 was released 2 weeks ago. Should the ports be updated to this version?

[macosx12345 <someuser12@…>]

In a80c814a092e0cb09e730dbe5f46f8dc3dbfb1c4/macports-ports (master):

cmake-devel: update to 3.27.1 (​https://github.com/macports/macports-ports/pull/19760)

Closes: #67540

[mascguy (Christopher Nielsen)]

It looks like upstream just released 3.27.2 today, but getting closer to parity.

[macosx12345 <someuser12@…>]

In d853ed4c4bf56af3cffb65ef752ef8c849c575e2/macports-ports (master):

cmake-devel: update to 3.27.2 (​https://github.com/macports/macports-ports/pull/19843)

See: #67540

[reneeotten (Renee Otten)]

why can we not follow the latest release for the cmake port? Version 3.27.2 was released a month ago, is there a concern for breaking something or is there no obvious reason for it. Also, the livecheck should be fixed as it currently doesn't work.

[jmaebe]

Patches to compile cmake 3.27.2

[jmaebe]

I've attached cmake.tar.bz2 with (I think) all files I had to add/change for the cmake port to be able to build cmake 3.27.2 on Mac OS X 10.6.

edit: note that I haven't actually tried to use the result yet :)

edit 2: I have used it now and it works fine

[asvitkine]

So what's needed to update cmake in ports? Some cmake projects now require a min cmake version that's above what macports offers...

[ryandesign (Ryan Carsten Schmidt)]

Replying to asvitkine:

So what's needed to update cmake in ports?

First, cmake-devel should be updated to the latest version (currently 3.28.3 but 3.29.0 is almost ready) and the port should be revised to use the bundled libuv instead of the libuv port; see #69449. A pull request is the best way to propose an update.

After verifying by looking at the buildbot results that it built successfully on all OS versions (Mac OS X 10.6 and up), the cmake port could be updated to the same version. However pay special attention to Mac OS X 10.7. The last several times we tried, building cmake-devel caused the 10.7 buildbot machine to kernel panic; see #68718. If that persists, I would not want to update to that version on 10.7 since it will pretty much kill our ability to build anything on 10.7.

[ryandesign (Ryan Carsten Schmidt)]

cmake-devel was updated to 20240322-3.29.1-cff8aefc in [1e8835fcec037e1a3f0e1af5d65558c45140e517/macports-ports].

[kencu (Ken)]

thanks Ryan -- I didn't look for such a ticket.

I'll fix cmake-devel to run on all systems and then push this update through to the cmake port, which is getting very outdated now.

The next version of pan2 builds with cmake, but requires a newer version of cmake than what we currently offer in the cmake port, for example.

[kencu (Ken)]

I'll look at using the bundled libuv before we move it to the cmake port. That should be quite trivial to do.

[kencu (Ken)]

oh, this ticket is also asking to update cmake.

might as well leave it open then until we do

[kencu (Ken)]

cmake-devel 20240322-3.29.1-cff8aefc does not build on 10.5 PPC, likely due to the issues noted here:

​https://gitlab.kitware.com/cmake/cmake/-/issues/25414#note_1473767

Trying to build it on 10.7 results in a full-on kernel panic (both in Parallels and on real 10.7 hardware) during the final link phase of the bootstrap cmake. I tried updating the linker to ld64-latest to see what that might do, but it made no difference.

Sat Mar 23 12:56:09 2024
panic(cpu 0 caller 0xffffff80002c4794): Kernel trap at 0xffffff8000536ae2, type 14=page fault, registers:
CR0: 0x00000000c0010033, CR2: 0x0000000000000004, CR3: 0x000000000f045021, CR4: 0x00000000000206e0
RAX: 0xffffff8011554130, RBX: 0x000000000000000b, RCX: 0xffffff8011554130, RDX: 0x0000000000000000
RSP: 0xffffff80f39d3430, RBP: 0xffffff80f39d3480, RSI: 0xffffff8012692870, RDI: 0xffffff8012639518
R8:  0x00007ffe63c1c000, R9:  0x0000000000000001, R10: 0xffffff80139a5d20, R11: 0x0000000000000000
R12: 0x0000000000000000, R13: 0x0000000000000008, R14: 0xffffff8012639668, R15: 0x000000000000000b
RFL: 0x0000000000010246, RIP: 0xffffff8000536ae2, CS:  0x0000000000000008, SS:  0x0000000000000010
CR2: 0x0000000000000004, Error code: 0x0000000000000000, Faulting CPU: 0x0

Backtrace (CPU 0), Frame : Return Address
0xffffff80f39d30e0 : 0xffffff8000220792 mach_kernel : _panic + 0x252
0xffffff80f39d3160 : 0xffffff80002c4794 mach_kernel : _kernel_trap + 0x6a4
0xffffff80f39d3310 : 0xffffff80002da55d mach_kernel : _return_from_trap + 0xcd
0xffffff80f39d3330 : 0xffffff8000536ae2 mach_kernel : _fdexec + 0x172
0xffffff80f39d3480 : 0xffffff800053fd5c mach_kernel : _kco_ma_addsample + 0x162c
0xffffff80f39d3890 : 0xffffff80005411b0 mach_kernel : _kco_ma_addsample + 0x2a80
0xffffff80f39d3ac0 : 0xffffff8000542386 mach_kernel : _posix_spawn + 0xab6
0xffffff80f39d3f50 : 0xffffff80005ce4cb mach_kernel : _unix_syscall64 + 0x1fb
0xffffff80f39d3fb0 : 0xffffff80002daea3 mach_kernel : _hndl_unix_scall64 + 0x13

BSD process name corresponding to current thread: cmake
Boot args: keepsyms=1 -serial=0x2

Mac OS version:
11G63

Kernel version:
Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64
Kernel UUID: FF3BB088-60A4-349C-92EA-CA649C698CE5
System model name: Parallels18,1 (Mac-7BA5B2D9E42DDD94)

System uptime in nanoseconds: 9241809597954
last loaded kext at 11561522267: com.apple.filesystems.smbfs	1.7.2 (addr 0xffffff7f807d9000, size 241664)
last unloaded kext at 82482540565: com.apple.driver.AppleFileSystemDriver	13 (addr 0xffffff7f8161a000, size 12288)
loaded kexts:
com.parallels.kext.tg	18.3.2 53621
com.parallels.kext.video	18.3.2 53621
com.apple.filesystems.smbfs	1.7.2
com.apple.filesystems.autofs	3.0
com.apple.driver.AudioAUUC	1.59
com.apple.driver.AppleHDA	2.2.5a5
com.apple.driver.AppleUpstreamUserClient	3.5.9
com.apple.driver.AppleMCCSControl	1.0.33
com.apple.iokit.IOUserEthernet	1.0.0d1
com.apple.iokit.IOBluetoothSerialManager	4.0.8f17
com.apple.Dont_Steal_Mac_OS_X	7.0.0
com.apple.driver.AudioIPCDriver	1.2.3
com.apple.driver.ApplePolicyControl	3.1.33
com.apple.driver.ACPI_SMC_PlatformPlugin	5.0.0d8
com.apple.iokit.SCSITaskUserClient	3.2.1
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless	1.0.0d1
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib	1.0.0d1
com.apple.BootCache	33
com.apple.driver.XsanFilter	404
com.apple.iokit.IOAHCISerialATAPI	2.0.3
com.apple.iokit.IOAHCIBlockStorage	2.1.0
com.apple.driver.AppleUSBHub	5.1.0
com.apple.driver.AppleEFINVRAM	1.6.1
com.apple.driver.AppleAHCIPort	2.3.1
com.apple.driver.AppleIntelPIIXATA	2.5.1
com.apple.driver.AppleHPET	1.7
com.apple.driver.AppleUSBEHCI	5.1.0
com.apple.driver.AppleUSBUHCI	5.1.0
com.apple.driver.AppleIntel8254XEthernet	2.1.3b1
com.apple.driver.AppleACPIButtons	1.5
com.apple.driver.AppleUSBXHCI	1.1.0
com.apple.driver.AppleRTC	1.5
com.apple.driver.AppleSMBIOS	1.9
com.apple.driver.AppleAPIC	1.6
com.apple.driver.AppleIntelCPUPowerManagementClient	195.0.0
com.apple.nke.applicationfirewall	3.2.30
com.apple.security.quarantine	1.4
com.apple.security.TMSafetyNet	8
com.apple.driver.AppleIntelCPUPowerManagement	195.0.0
com.apple.kext.triggers	1.0
com.apple.driver.DspFuncLib	2.2.5a5
com.apple.driver.AppleSMBusController	1.0.10d0
com.apple.iokit.IOSMBusFamily	1.1
com.apple.iokit.IOSurface	80.0.2
com.apple.iokit.IOSerialFamily	10.0.5
com.apple.iokit.IOAudioFamily	1.8.6fc18
com.apple.kext.OSvKernDSPLib	1.3
com.apple.driver.AppleHDAController	2.2.5a5
com.apple.iokit.IOHDAFamily	2.2.5a5
com.apple.driver.AppleGraphicsControl	3.1.33
com.apple.iokit.IONDRVSupport	2.3.4
com.apple.driver.AppleSMC	3.1.3d10
com.apple.driver.IOPlatformPluginLegacy	5.0.0d8
com.apple.driver.IOPlatformPluginFamily	5.1.1d6
com.apple.iokit.IOGraphicsFamily	2.3.4
com.apple.driver.AppleUSBHIDKeyboard	160.7
com.apple.driver.AppleHIDKeyboard	160.7
com.apple.iokit.IOUSBHIDDriver	5.0.0
com.apple.driver.AppleUSBComposite	5.0.0
com.apple.iokit.IOSCSIMultimediaCommandsDevice	3.2.1
com.apple.iokit.IOBDStorageFamily	1.7
com.apple.iokit.IODVDStorageFamily	1.7.1
com.apple.iokit.IOCDStorageFamily	1.7.1
com.apple.iokit.IOSCSIArchitectureModelFamily	3.2.1
com.apple.iokit.IOUSBUserClient	5.0.0
com.apple.iokit.IOAHCIFamily	2.0.8
com.apple.iokit.IOATAFamily	2.5.1
com.apple.driver.AppleEFIRuntime	1.6.1
com.apple.iokit.IONetworkingFamily	2.1
com.apple.iokit.IOHIDFamily	1.7.1
com.apple.iokit.IOUSBFamily	5.1.0
com.apple.security.sandbox	177.11
com.apple.kext.AppleMatch	1.0.0d1
com.apple.driver.DiskImages	331.7
com.apple.iokit.IOStorageFamily	1.7.2
com.apple.driver.AppleKeyStore	28.18
com.apple.driver.AppleACPIPlatform	1.5
com.apple.iokit.IOPCIFamily	2.7
com.apple.iokit.IOACPIFamily	1.4

That last 10.7 error is a bit strange, given 10.6 builds through both 32 and 64 bit, but there are many reasons why 10.7 might fail whereas 10.6 did not, and we know that in general, 10.7 and cmake have always been pretty touchy.

10.5 builds fine using 3.28.4. I'll try that on 10.7 and see how it fares.

[kencu (Ken)]

Ryan saw kernel panics on 10.7 building 3.28.0-rc1 as well, here #68718.

[kencu (Ken)]

Installing cmake-devel 3.28.4 proceeds without issue:

$ port -v installed cmake-devel
The following ports are currently installed:
  cmake-devel @20240322-3.28.4-b5602e72_0 (active) requested_variants='' platform='darwin 11' archs='x86_64' date='2024-03-23T13:17:11-0700'

[kencu (Ken)]

I would suspect the issue with 10.7's kernel panics is related to the issue that causes 10.5 PPC to fail (ie libuv changes).

I'm not sure if cmake plans to roll the reverts done in the 3.28.N branch into the 3.29.N branch. They likely will, I expect, if they can't fix them.

For now, it appears we can use 3.29.N on 10.6 and 10.8+, and 3.28.4 on 10.7 and < 10.6. That is slightly disjointed, but - as 10.6 seems OK with 3.29.N, might as well use it there...

Barracuda's 10.6-PPC system is an unknown quantity in this, ATM.

[kencu (Ken)]

@barracuda reports a build failure of 3.29.N on 10.6 PPC (I think) -- 10.6 Intel was fine on the buildbots.

[kencu (Ken)]

In f3fec17f75a924b262ddd050bd6505f54b713220/macports-ports (master):

cmake-devel: hold back to 3.28.4 on failing systems

10.7 has a kernel panic building 3.29.N
10.5 (and less presumably) error out due to spawn issues

see: #67540

[kencu (Ken)]

re: spawn issues:

this looks like where libuv introduced it

​https://github.com/libuv/libuv/pull/3064

other projects have had issues with new libuv spawn procedure and force the old fork behavior:

​https://github.com/MagicStack/uvloop/pull/571/commits/d7b9df7883ee9c54b291fdd68fdd11c04376d5c9

this old comment from ben outlines some issues that look relevant to me

​https://github.com/joyent/libuv/issues/1483

this macports patch doesn’t look like it is doing the right thing to me

[ab7ce9a21b34a68d659a024ca8238c663af737f7/macports-ports]

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

this macports patch doesn’t look like it is doing the right thing to me

[ab7ce9a21b34a68d659a024ca8238c663af737f7/macports-ports]

I don't see an upstream bug report reference in that patch. But the PR that added it says it came from a patch in the libuv port. I guess that's source:macports-ports/devel/libuv/files/patch-libuv-legacy.diff​. I don't see an upstream bug report reference in that patch either though. Looks like it came from ​https://github.com/macports/macports-ports/pull/14225#issuecomment-1066095939.

[kencu (Ken)]

It appears this define in this spot would control whether process behaviour is attempted. The fallback is fork behaviour is used.

​https://github.com/libuv/libuv/blob/6adeeacee7eb997d60552351b43d65b494745700/src/unix/process.c#L862

[kencu (Ken)]

and indeed, tweaking our blocker to force the fork behaviour always on older systems fixes 10.7. Let me try 10.5 PPC now.

#if defined(__APPLE__) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 1080)
  uv_once(&posix_spawn_init_once, uv__spawn_init_posix_spawn);

[kencu (Ken)]

In be1094bc8810d5776303041e34ae5e022fd755b4/macports-ports (master):

cmake-devel: update libuv patchfile

force fork behaviour on all systems < 10.8
see #67540
see #68718

[kencu (Ken)]

The issues with using posix_spawn in libuv on some systems seem to be being investigated here:

​https://github.com/libuv/libuv/issues/4279

The discussion is technical, but a race condition is being suspected AFAICT.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

cmake-devel: update libuv patchfile

Does this change require a revision increase?

Does this change mean that 3.29.x would now work and the port could be updated to that version for 10.7 and for <= 10.5?

[kencu (Ken)]

both done, yes.

well, version date was updated instead of revision, but same effect

[kencu (Ken)]

[5ad437db3d850cd98c0c232afff3ccdb7697ec81/macports-ports]