go @1.12 fails to build on mavericks

[tehcog (tehcog)]

Please see log for full details

:info:build go tool dist: FAILED: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_go/go/work/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: signal: trace/BPT trap
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_go/go/work/go/src" && ./make.bash 
:info:build Exit code: 2
:error:build Failed to build go: command execution failed
:debug:build Error code: CHILDSTATUS 5814 2
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_go/go/main.log for details.

[tehcog (tehcog)]

log

[kencu (Ken)]

This one may turn out to be interesting:

:info:build Building Go toolchain2 using go_bootstrap and Go toolchain1.
:info:build dyld: Symbol not found: _unlinkat
:info:build   Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_go/go/work/go/pkg/tool/darwin_amd64/go_bootstrap

The legacy-support port offers an implementation of that symbol:

$ nm /opt/local/lib/libMacportsLegacySupport.dylib | grep unlinkat
00000000000027a0 T _unlinkat

[tehcog (tehcog)]

bump?

[Ionic (Mihai Moldovan)]

The go build system is... something very special.

I wasn't yet able to pass the legacy support LDFLAGS to the go_bootstrap builder - at least not in a way that would correctly link it in the end.

[Ionic (Mihai Moldovan)]

I think I managed to pass the required options, but even with the legacy support library, building fails due to a missing _fstatat64 symbol. The library really doesn't have that - or any other *64 counterparts.

[Ionic (Mihai Moldovan)]

To make matters even more complicated, ​go recently (1.12) starting importing and using libSystem.dylib instead of using syscalls on OS X/macOS. That COULD mean that additional libraries are not searched for when looking for symbols, but that needn't be.

Regarding fstat64: ​they already had their share of problems with that one and ​had to turn it off on iOS, because Apple regards the 64-postfixed variants as either deprecated (for older syscalls) or completely private A[BP]I (for newer ones like fstatat) - and private A[BP]I might not be used in applications submitted to the App Store. Manual pages for OS X/macOS seem to indicate that this is true there as well, so the 64-postfixed variants should be removed in gos darwin support infrastructure as well, but that's a bug for upstream, not us. What's more, recent iOS versions seem to set _DARWIN_FEATURE_ONLY_64_BIT_INODE and make the 64-postfixed syscall versions accessible as the default. I'd have to check how that is on OS X/macOS, but chances are

Generally, though, it feels like libMPLegacySupport should add support for the 64-postfixed variants, even if only as aliases for the already implemented functions.

[Ionic (Mihai Moldovan)]

I finally have a working go 1.12.1 build on OS X 10.9

It's horrid, but it bootstrapped itself successfully. It likely won't work out of the box for users (i.e., in the case users want actually use go on their go source code), but there isn't anything I can do about that, I guess.

Users will have to disable the internal linker/force the external linker and at the very least pass the external LDFLAGS -L${prefix} -lMacportsLegacySupport for binaries to work, I guess, if they are using any features provided by legacy-support (even pulled in via the core).

Is this acceptable?

I'm going to polish up the Portfile tomorrow and submit a PR to legacy-support for fstatat64 support. Without that, it won't work, so we'd probably need a legacy-support release/RC with that new fstatat64 support in before the go port can be fixed.

[tehcog (tehcog)]

Replying to Ionic:

Users will have to disable the internal linker/force the internal linker and at the very least pass the external LDFLAGS -L${prefix} -lMacportsLegacySupport for binaries to work, I guess, if they are using any features provided by legacy-support (even pulled in via the core).

Is this acceptable?

I guess it will have to be \ 0_o / Thanks.

[Ionic (Mihai Moldovan)]

Suggested build fix for older platforms. Maintainer, please review. I'll push it myself, probably within the next few days.

[Mihai Moldovan <ionic@…>]

In abe46d0764f08fdec9a4923880ce03edbc768a0d/macports-ports (master):

lang/go: support older OS versions using legacysupport PG.

Fixes: #58138

This adds a simple patch and changes the go build procedure to inject
the legacy-support library into all compiled binaries, getting support
for 10.9 and probably older OS versions.

Users will have to do the same when compiling go programs, the new note
details this process.

A separate patch is needed to workaround a base bug which won't let
ports define environment variables with a quote character in them. Since
base is fixed, this is conditional and not used for newer base versions.