Opened 10 months ago
Closed 9 months ago
#69160 closed defect (fixed)
go @1.17.13: Bad CPU type in executable
Reported by: | leeeoooooo | Owned by: | ci42 |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.1 |
Keywords: | i386 snowleopard | Cc: | herbygillot (Herby Gillot), barracuda156, mascguy (Christopher Nielsen) |
Port: | go |
Description
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.
Attachments (1)
Change History (15)
Changed 10 months ago by leeeoooooo
Attachment: | micro.go.main.log added |
---|
comment:1 follow-up: 2 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | herbygillot added |
---|---|
Keywords: | snowleopard added; micro go removed |
Owner: | set to ci42 |
Port: | micro -> removed |
Status: | new → assigned |
Summary: | go will not build - "bad CPU type" → go @1.17.13: Bad CPU type in executable |
go requires a fairly recent version of macOS to work well...
comment:2 Changed 9 months ago by 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.
comment:3 Changed 9 months ago by barracuda156
Cc: | barracuda156 added |
---|
comment:4 Changed 9 months ago by barracuda156
Oh well, of course this cannot possibly work, it is broken by design now:
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.
comment:5 Changed 9 months ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:6 Changed 9 months ago by 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.
comment:7 Changed 9 months ago by 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.
comment:8 Changed 9 months ago by barracuda156
This was very annoying, their build system is broken.
- To have build arch set correctly,
GOHOSTARCH=${GOARCH}
is needed.GOARCH
is ignored. - Trash unsupported
-no_pie
inlib.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
comment:9 follow-up: 10 Changed 9 months ago by 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
comment:10 Changed 9 months ago by kencu (Ken)
Replying to barracuda156:
Well,
legacysupport
does not seem to haveINODE64
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:
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
comment:11 Changed 9 months ago by kencu (Ken)
Basically, different archs have different supports for those symbols in the system. Apple designed it that way.
comment:12 follow-up: 13 Changed 9 months ago by kencu (Ken)
comment:13 Changed 9 months ago by 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.
comment:14 Changed 9 months ago by barracuda156
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
go build log