gh: Error: Failed to destroot gh: dyld: Symbol not found: _exit

[RobK88]

The port gh fails to destroot on El Capitan and Mtn Lion:

Error: Failed to destroot gh: dyld: Symbol not found: _exit

It looks like legacy-support does not handle the _exit symbol.

I do hope someone can add this symbol to legacy-support. It should be easy considering the nature of the symbol.

[RobK88]

main.log

[fhgwright (Fred Wright)]

I'll take a look at it, though it's bizarre that legacy-support would be relevant for something as basic as _exit.

At least gh has minimal dependencies, so it shouldn't be a big hassle to reproduce.

[fhgwright (Fred Wright)]

OK, the problem is this:

DEBUG: system -W /opt/local/var/macports/build/_opt_local_var_macports_sources_MacPro.local_rsync.macports.org_macports_release_tarballs_ports_devel_gh/gh/work/destroot/opt/local/bin: install_name_tool -change /usr/lib/libSystem.B.dylib /opt/local/lib/libMacportsLegacySupport.dylib gh

This is patching gh to use libMacportsLegacySupport.dylib instead of libSystem.B.dylib, which doesn't work, since libMacportsLegacySupport.dylib only provides added functions. It would presumably complain about a zillion other missing definitions if it didn't stop on the first error.

In most cases, builds using legacy-support arrange to use libMacportsLegacySupport.dylib in addition to the normal system library(s), not instead of. However, to accomodate situations such as this where that's not an option, it also provides libMacportsLegacySystem.B.dylib, which includes a passthrough for libSystem.B.dylib. From the Portfile comment, it looks like it expects that behavior, and just uses the wrong library.

A quick check on 10.9 shows that fixing the library name fixes that bug, though it now gets:

Error: Failed to destroot gh: dyld: Symbol not found: _notify_is_valid_token

There's already a long-standing ticket #67520 for that, so this fix alone won't help systems older than 10.10 (including 10.8).

[RobK88]

Thanks Fred for doing some troubleshooting.

In my view, the real solution is for someone to patch a much newer version of go to work on legacy Mac systems. If that is too much work, we should just limit the gh port (and other go based ports) to newer versions of macOS.

[fhgwright (Fred Wright)]

AIUI, go is self-hosted, meaning that a working version of go is needed to build go, hence the current approach. "Just fix the source" isn't an option until after one has a working binary. The only version requirement for the bootstrap binary is that it be sufficiently recent to support the build procedure, and moving to a "much newer version" is exactly the wrong thing, because it's likely to make the OS requirements worse.

There are actually several problems with gh as it stands, aside from the issue here:

1) It also needs utimensat(), which didn't appear until 10.13. That one is trivially fixed by changing the version threshold for the legacy-support patch. In fact, it means that legacy-support is needed for all binary versions, so the extra conditional goes away.

2) In addition to the aforementioned #67520, #66749 is also relevant.

3) The binary doesn't include i386 or ppc slices.

4) The binary uses a load command that's unsupported on 10.5 (and presumably 10.4, if it got past the architecture issue).

5) The builds from source on 10.13 and 10.14 don't work, due to some quoting issue with command arguments.

The bottom line is that gh doesn't currently work on anything older than 10.15, even with the easy fixes.

[RJVB (René Bertin)]

But which older version would still work? I tried 1.14 (relinked to the proper legacy-support library) but that version succombs to runtime syntax errors (which might be nodejs related because apparently using just 1 alternative programming language wasn't enough...)