go @1.17.13: Bad CPU type in executable

[leeeoooooo]

I'm trying to install the micro text editor underMac OS X 10.6.8 on my 2006 white polycarbonate MacBook1,1 with a 32-bit-ONLY Core Duo "Yonah" CPU. Apparently, micro is dependent on go and go is having trouble building on my CPU. Please see log.

[leeeoooooo]

go build log

[ryandesign (Ryan Carsten Schmidt)]

go requires a fairly recent version of macOS to work well...

[barracuda156]

Replying to ryandesign:

go requires a fairly recent version of macOS to work well...

The problem here is that the port installs a wrong bootstrap binary – it is x86_64-only. This is a bug on the portfile side (whether it will work is to be determined). I have no idea at the moment if go 1.17.13 existed for i386, but if not, it should use an older version for bootstrapping.

[barracuda156]

Oh well, of course this cannot possibly work, it is broken by design now:

​https://github.com/macports/macports-ports/blob/74d67724f89b6214d3ec94b7863af23f613ee969/lang/go/Portfile#L29

This is set to false, nothing down changes that, so instead of using Go-1.4 for bootstrap it tries to use a new prebuilt binary, but distfiles do not even contain a mention of 386 binary and the build is set to use x86_64.

Unfortunately, just fixing this is not enough to fix the build, since even using Go-1.4, it still switches to building for x86_64, and also uses unsupported linker flags like -no_pie. So at the very minimum we need to a) fix choice of build type; b) patch out breaking ldflags and c) ensure correct arch is used across the build. Then maybe it will work.

[barracuda156]

Last version of Go to support i386 out-of-the-box is 1.14. Upstream has broken it in ​https://github.com/golang/go/commit/d5e1b7ca68e2cc484d9a1517bdc0a9862936a1eb and some earlier commits for 1.15.

Also: ​https://go.dev/doc/go1.14

[barracuda156]

While I do not love i386 that much to bother forward-porting support for it, I think I can fix the port to build 1.14.14 for it. Such implementation may be helpful for PowerPC, if we ever have time to fix that.

[barracuda156]

This was very annoying, their build system is broken.

1. To have build arch set correctly, GOHOSTARCH=${GOARCH} is needed. GOARCH is ignored.
2. Trash unsupported -no_pie in lib.go.

Then need to fix this:

run: /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/go/pkg/tool/darwin_386/link -extldflags=-Wl,-headerpad_max_install_names -L/opt/local/lib -lMacportsLegacySupport -extld=/usr/bin/gcc-4.2 -o /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/go/pkg/tool/darwin_386/go_bootstrap /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-tool-dist-132141453/cmd/go/_go_.a
/opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/go/pkg/tool/darwin_386/link: running /usr/bin/gcc-4.2 failed: exit status 1
ld warning: atom sorting error for _runtime.erodata and _runtime.etypes in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.etypes and _runtime.erodata in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.etypes and _runtime.erodata in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.etypes and _runtime.erodata in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.erodata and _runtime.etypes in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.erodata and _runtime.etypes in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.erodata and _runtime.etypes in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: can't parse dwarf compilation unit info in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
ld warning: atom sorting error for _runtime.erodata and _runtime.etypes in /opt/local/var/macports/build/_opt_SnowLeopardPorts_lang_go/go/work/.tmp/go-link-377917722/go.o
Undefined symbols:
  "_fdopendir$INODE64$UNIX2003", referenced from:
      _syscall.libc_fdopendir_trampoline in go.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

[barracuda156]

Well, legacysupport does not seem to have INODE64 version:

sergey-fedorovs-mac-mini:macports-ports svacchanda$ nm -arch i386 -g /opt/local/lib/libMacportsLegacySupport.dylib |grep fdopendir
0000478a T _fdopendir$UNIX2003

[kencu (Ken)]

Replying to barracuda156:

Well, legacysupport does not seem to have INODE64 version:

sergey-fedorovs-mac-mini:macports-ports svacchanda$ nm -arch i386 -g /opt/local/lib/libMacportsLegacySupport.dylib |grep fdopendir
0000478a T _fdopendir$UNIX2003

Read this:

​https://github.com/macports/macports-legacy-support/blob/c440f888d35e4486b0ae6ff5cd715b9d1df56d3c/Makefile#L170

That was put together 5 years ago, and it's correct.

You still have lots to catch up on.

See also:

​https://github.com/macports/macports-legacy-support/commit/a33d8e6ffe89eba9cee68845fa6878d8e9b27ef7

[kencu (Ken)]

Basically, different archs have different supports for those symbols in the system. Apple designed it that way.

[kencu (Ken)]

More in here

​https://github.com/macports/macports-legacy-support/pull/24

[barracuda156]

Replying to kencu:

More in here

​https://github.com/macports/macports-legacy-support/pull/24

Thank you, I will sort it out for my legacysupport. Chances are I will get Go-1.14 building, maybe even today.

[barracuda156]

In 0435fe55210208e7d4f4ec6b4954a7d746a1a971/macports-ports (master):

go: unbreak i386

Fixes: #69160
Fixes: #64169