Opened 9 months ago
Closed 8 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 9 months ago by leeeoooooo
Attachment: | micro.go.main.log added |
---|
comment:1 follow-up: 2 Changed 9 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 8 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 8 months ago by barracuda156
Cc: | barracuda156 added |
---|
comment:4 Changed 8 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 8 months ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:6 Changed 8 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 8 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 8 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 8 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 8 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 8 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 8 months ago by kencu (Ken)
comment:13 Changed 8 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 8 months ago by barracuda156
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
go build log