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: some packages don't build with -buildmode=shared #25065

Open
pebbe opened this Issue Apr 25, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@pebbe
Contributor

pebbe commented Apr 25, 2018

Please answer these questions before submitting your issue. Thanks!

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

go version go1.9.5 linux/amd64
go version go1.10.1 linux/amd64

Does this issue reproduce with the latest release?

yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/tmp/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/peter/go"
GORACE=""
GOROOT="/my/opt/go"
GOTMPDIR="/tmp"
GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build569417713=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I tried to install the package github.com/pebbe/util in lgo (github.com/yunabe/lgo). The package installs and works fine as a regular, static package. But lgo tries to build shared packages, and that fails.

I don't know what is going on, but this might be a bug in Go with -buildmode=shared

You can find a detailed description here: yunabe/lgo#57

@ianlancetaylor ianlancetaylor changed the title from Some packages don't build with -buildmode=shared to cmd/link: some packages don't build with -buildmode=shared Apr 25, 2018

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Apr 25, 2018

yunabe added a commit to yunabe/gobug25065 that referenced this issue May 30, 2018

@yunabe

This comment has been minimized.

yunabe commented May 30, 2018

I created a repository to reproduce this issue with minimum code
https://github.com/yunabe/gobug25065

cmd/link fails when a method A is defined as func (m myType) A() {} and it is referenced by (*myType).A.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented May 30, 2018

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented May 31, 2018

Hm my fix for #22998 doesn't seem to fix this. Will need to make some time to dig properly into this.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jun 23, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Dec 8, 2018

If I run

go tool compile -shared -o foo.a GOPATH/github.com/yunabe/gobug25065/src.go

then go tool nm shows

    1187 R %22%22.(*myType).A·f

If I run

go tool compile -shared -dynlink -o foo.a GOPATH/github.com/yunabe/gobug25065/src.go

(that is, add the -dynlink option) then go tool nm shows

     U %22%22.(*myType).A·f

So it seems that when using -dynlink the symbol really is undefined.

@gopherbot

This comment has been minimized.

gopherbot commented Dec 8, 2018

Change https://golang.org/cl/153297 mentions this issue: cmd/compile: emit a symbol for a method expression when using -dynlink

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