gtk3: gtk-encode-symbolic-svg hangs with adwaita-icon-theme on MacOS

[lukaso (Lukas Oberhuber)]

​https://gitlab.gnome.org/GNOME/gtk/-/issues/5645

Copying the issue content from there to here...

gtk-encode-symbolic-svg crashes MacOS Ventura 13.2.1

When installing the MacPorts version of adwaita-icon-theme on MacOS, the installation part (post-build) hangs indefinitely with iterm2 indicating it is running gtk-encode-symbo which can only be gtk-encode-symbolic-svg. When this occurs, I am unable to launch new terminals in either iterm2 or terminal. Also, all networking seems to break as I can't load new browser pages. My only solution was to reboot the Mac. Then things went back to normal. This occurred twice.

In fact, the reboot function also did not work and I had to hard reboot to recover the machine. This has never occurred before.

[lukaso (Lukas Oberhuber)]

This is now consistently hanging my Mac and forcing a hard boot, which means I am no longer able to build GIMP on my local mac.

[lukaso (Lukas Oberhuber)]

Build log of a hanging build

[lukaso (Lukas Oberhuber)]

When I went into the local build following the instructions here: wiki:howto/PatchLocal, it worked fine.

I ran

sudo make
sudo make install

I suspect something with tcl not interacting well with the wait command in the build script maybe?

[ryandesign (Ryan Carsten Schmidt)]

I'm not sure, but it looks like they try to spawn a bazillion simultaneous install-sh commands, then wait for them all to finish, then do it again. It's certainly possible that there is a bug in macOS such that it can't handle spawning a lot of simultaneous processes. We've seen that before with the way that MacPorts base spawns ping processes to find which servers are closest to you; see #61683.

Try rewriting the Makefile so that it does things sequentially (remove the & at the end of each install-sh; you can remove the wait too but it wouldn't matter if you left it in since there wouldn't be any background processes to wait for).

[lukaso (Lukas Oberhuber)]

When I ran it from the port directory without MacPorts in the way, I didn't run into problems, so I wonder if the extra level of indirection is causing the problem.

So yes, a slower, but reliable version without the background tasks is probably the right solution.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts isn't only an extra level of indirection; it also enables features you wouldn't have enabled in your normal shell, like sandboxing. (This ensures that improperly-programmed ports cannot write files outside of the destroot directory, for example.)

[mascguy (Christopher Nielsen)]

This is just a shot in the dark, but you might want to try using the alternative GNU utilities during the build: coreutils (which will supply gmkdir, among other things), plus gmake, gsed, and gawk.

Most of this can be accomplished simply by adding those ports as build deps. Along with setting build.cmd to ${prefix}/bin/gmake.

I have no idea whether all of that will make any difference. But it might be worth testing.

[mascguy (Christopher Nielsen)]

Replying to mascguy:

This is just a shot in the dark, but you might want to try using the alternative GNU utilities during the build: coreutils (which will supply gmkdir, among other things), plus gmake, gsed, and gawk.

Most of this can be accomplished simply by adding those ports as build deps. Along with setting build.cmd to ${prefix}/bin/gmake.

Another option you can try: Use a RAM disk for the MacPorts build area, formatted as HFS+:

$ sudo bash -c 'dev=$(hdiutil attach -nomount ram://16777216) ; newfs_hfs -s -v "MacPorts-RamDisk-8G" ${dev} ; mount -t hfs ${dev} /opt/local/var/macports/build'

That removes APFS from the equation, and might make a difference.

[mascguy (Christopher Nielsen)]

Per Lukas' latest message on the upstream issue, this is no longer a problem:

To be honest, once I was able to get it installed by commenting out the parallel calls, I’ve avoided messing with it since it only happens on my local Mac, not on the ci devices.

​https://gitlab.gnome.org/GNOME/gtk/-/issues/5645#note_1739818

[lukaso (Lukas Oberhuber)]

Per Lukas' latest message on the upstream issue, this is no longer a problem:

To be honest, once I was able to get it installed by commenting out the parallel calls, I’ve avoided messing with it since it only happens on my local Mac, not on the ci devices.

​​https://gitlab.gnome.org/GNOME/gtk/-/issues/5645#note_1739818

I think you misunderstood. It is very much a problem, just that I was able to work around it and given my severely limited time for focusing on GIMP, I couldn't dig into it. It will 100% come back to haunt me (and us). I think the easy solution is to comment out the parallel copies in the build script as a patch. That was my workaround.

[mascguy (Christopher Nielsen)]

Replying to lukaso:

I think you misunderstood. It is very much a problem, just that I was able to work around it and given my severely limited time for focusing on GIMP, I couldn't dig into it. It will 100% come back to haunt me (and us). I think the easy solution is to comment out the parallel copies in the build script as a patch. That was my workaround.

No worries, I misunderstood. If you can provide a patch, we'll happily apply it!

[lukaso (Lukas Oberhuber)]

OK, I've created a patch in ​https://github.com/macports/macports-ports/pull/18646

That took several hours because of how hard it is to do this kind of thing in MacPorts. I understand that's a hard thing to fix, but it would be amazing if it was much easier to create a patch.

Anyway, thanks for listening.

[lukaso (Lukas Oberhuber)]

In f3d50a3bf7568b0da8041ef8a3363652a2c34d21/macports-ports (master):

adwaita-icon-theme: patch to disable parallel processing
Fixes: #67243