New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: wrong c-archive architecture using GNU binutils ar on macOS Mojave 10.14.1 #28796

Open
DemonWav opened this Issue Nov 14, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@DemonWav
Contributor

DemonWav commented Nov 14, 2018

What version of Go are you using (go version)?

$ go version
go version go1.11.2 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/kyle/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/kyle/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vw/ht92mdqd1f54_c6ys42ltc5c0000gn/T/go-build035928823=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Following the instructions at https://golang.org/doc/install/source, with the latest 1.11.2 darwin/amd64 Go binary distribution as the bootstrap toolchain:

git clone https://go.googlesource.com/go gosrc
cd gosrc
git checkout go1.11.2
cd src
./all.bash

What did you expect to see?

Go project should build successfully.

What did you see instead?

Error log: https://gist.github.com/DemonWav/8caf4fbdf9642133f53502614a231a24

Issues occur with ##### ../misc/cgo/testcarchive. I believe the issue is with this line:

ld: warning: ignoring file pkg/darwin_amd64/libgo.a, file was built for archive which is not the architecture being linked (x86_64): pkg/darwin_amd64/libgo.a

Since the architecture doesn't match, it doesn't link, and the linker can't find the missing symbols.

If I instead ask for the 386 architecture (GOARCH=386 ./all.bash), it builds successfully: https://gist.github.com/DemonWav/533894d4426e6a9dc7cc84cc613ee66d

The host is still recognized as amd64 in the build log, though.

Building packages and commands for host, darwin/amd64.
Building packages and commands for target, darwin/386

It appears libgo is always compiled as i386 architecture, even when both host and target are defined as amd64, GOARCH=amd64 GOHOSTARCH=amd64 ./all.bash gives the same result.

I'm not sure if there's something wrong with my environment or what, but I've asked on Slack and IRC and no one seems to know. I'm sorry if this isn't an issue.

@ianlancetaylor ianlancetaylor changed the title from go/build: cgo build failure for 1.11.2 for darwin/amd64 on macOS Moave 10.14.1 to cmd/link: wrong c-archive architecture for 1.11.2 for darwin/amd64 on macOS Mojave 10.14.1 Nov 14, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Nov 14, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 14, 2018

What ar program is first on your PATH?

@DemonWav

This comment has been minimized.

Contributor

DemonWav commented Nov 14, 2018

My ar is the GNU utils command from the binutils package from Homebrew:

┌─┤✓├─┤kyle├─┤~│
└──▶ ar --version
GNU ar (GNU Binutils) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

┌─┤✓├─┤kyle├─┤~│
└──▶ which ar
/usr/local/bin/ar

┌─┤✓├─┤kyle├─┤~│
└──▶ ls -l /usr/local/bin/ar
lrwxr-xr-x 1 kyle admin 34 Nov  9 10:01 /usr/local/bin/ar -> ../Cellar/binutils/2.31.1_2/bin/ar

┌─┤✓├─┤kyle├─┤~│
└──▶ /usr/bin/ar --version
usage:  ar -d [-TLsv] archive file ...
	ar -m [-TLsv] archive file ...
	ar -m [-abiTLsv] position archive file ...
	ar -p [-TLsv] archive [file ...]
	ar -q [-cTLsv] archive file ...
	ar -r [-cuTLsv] archive file ...
	ar -r [-abciuTLsv] position archive file ...
	ar -t [-TLsv] archive [file ...]
	ar -x [-ouTLsv] archive [file ...]

So if I prioritize the default utils instead, it actually does work:

$ PATH="/usr/bin:$PATH" ./all.bash
.
.
.
ALL TESTS PASSED
---
Installed Go for darwin/amd64 in /Users/kyle/gosrc
Installed commands in /Users/kyle/gosrc/bin
*** You need to add /Users/kyle/gosrc/bin to your PATH.

So something about the GNU utils doesn't work with the Go build. I can keep that in mind, but it would be really nice if that could be supported directly, if possible.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 14, 2018

Could you examine the output of the system default ar program and the GNU binutils ar program and see what the difference is? Is there some option we could pass to the GNU ar program that will make it do the right thing?

@DemonWav

This comment has been minimized.

Contributor

DemonWav commented Nov 14, 2018

I'm not familiar with ar, sorry. Some quick research didn't reveal anything interesting, they seem to be supposed to do the same thing. It's easier for me to just uninstall the binutils package, I only had it installed for the sake of using GNU utils, but I don't need it directly. I don't know if you want to keep the issue open for the sake of supporting GNU utils on macOS or just close it for now, so I'll leave that to you.

@ianlancetaylor ianlancetaylor changed the title from cmd/link: wrong c-archive architecture for 1.11.2 for darwin/amd64 on macOS Mojave 10.14.1 to cmd/link: wrong c-archive architecture using GNU binutils ar on macOS Mojave 10.14.1 Nov 14, 2018

@ianlancetaylor ianlancetaylor modified the milestones: Go1.12, Unplanned Nov 14, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 14, 2018

I will leave this open in the hopes that someone using MacOS can look into it. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment