cmd/go: go install -buildmode=shared with no directory name generates bad shared library name

[avdva]

Go v 1.5. Fedora 22 x86_64

1. Compile and install the package named "worker":
   go install -buildmode=shared -linkshared
2. Try to compile another package, which imports "worker":
   go build -linkshared
go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 gcc: error: missing argument to ‘-l’
   Output with the '-x' option:
   /home/user/dev/go/pkg/tool/linux_amd64/link -o $WORK/godev/proj/_obj/exe/a.out -L $WORK -L /home/user/dev/godev/pkg/linux_amd64_dynlink -installsuffix dynlink -extld=gcc -buildmode=exe -buildid=98b4ec39a65525d2ee4614652117b2ad4dfdeb26 -linkshared -w $WORK/godev/proj.a /home/user/dev/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 gcc: error: missing argument to ‘-l
   The same command with '-x --compiler=gccgo' option produces the following:
   /usr/bin/gccgo -o $WORK/godev/testgo/_obj/exe/a.out $WORK/godev/testgo/_obj/_go_.o -Wl,-( -m64 -Wl,-) -L/home/user/dev/godev/pkg/gccgo_linux_amd64_fPIC/shlibs -Wl, -rpath=/home/user/dev/godev/pkg/gccgo_linux_amd64_fPIC/shlibs -l -Wl,-E -fPIC
   The output is:
   /usr/bin/ld: cannot find -l-Wl,-E collect2: error: ld returned 1 exit status
   It compiles well without -linkshared. Is there an error, or I just misuse these options?

[ianlancetaylor]

It would be very helpful if you could provide complete reproduction instructions, by which I mean the contents of the files you are compiling, the names of the directories they are in, etc. Your current description is sort of vague; when I do the exact same steps it works fine. There is something different about what you are doing, and the more details you can provide the more likely it is that we can figure out what it is. Thanks.

[avdva]

1. Clean go 1.5 installation from golang.org
2. Let ~/dev/gopath will be GOPATH, and into /src/ I put 2 folders: lib with lib.go and exe with exe.go
3. cat lib.go

package lib
 func init() {
        print("package lib")
 }

4. GOROOT=~/Apps/go-1.5-linux_amd64-vanilla/ GOPATH=~/dev/gopath/ ~/Apps/go-1.5-linux_amd64-vanilla/bin/go install -linkshared -buildmode=shared produces
   multiple roots /home/avd/dev/gopath/pkg/linux_amd64_dynlink & /home/avd/Apps/go-1.5-linux_amd64-vanilla/pkg/linux_amd64_dynlink
   So, according to that, I run GOROOT=~/Apps/go-1.5-linux_amd64-vanilla/ GOPATH=~/dev/gopath/ ~/Apps/go-1.5-linux_amd64-vanilla/bin/go install -linkshared -buildmode=shared std
   After it installation goes fine.
5. cd ../exe/, cat exe.go

package main
import (
    _ "lib"
)
func main() {

}

GOROOT=~/Apps/go-1.5-linux_amd64-vanilla/ GOPATH=~/dev/gopath/ ~/Apps/go-1.5-linux_amd64-vanilla/bin/go install -linkshared

/home/avd/Apps/go-1.5-linux_amd64-vanilla/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 gcc: error: missing argument to ‘-l’
Probably, I do something wrong with go install -buildmode=shared -linkshared std?
If i run it without -linkshared, I get this when installing exe:
# /tmp/go-build059541814/lib.so sync/atomic.StorePointer: sync/atomic.StoreUintptr: not defined sync/atomic.SwapPointer: sync/atomic.SwapUintptr: not defined sync/atomic.CompareAndSwapPointer: sync/atomic.CompareAndSwapUintptr: not defined runtime.sync_atomic_CompareAndSwapUintptr·f: sync/atomic.CompareAndSwapUintptr: not defined runtime.sync_atomic_StoreUintptr·f: sync/atomic.StoreUintptr: not defined runtime.sync_atomic_SwapUintptr·f: sync/atomic.SwapUintptr: not defined sync/atomic.StorePointer: undefined: sync/atomic.StoreUintptr sync/atomic.SwapPointer: undefined: sync/atomic.SwapUintptr sync/atomic.CompareAndSwapPointer: undefined: sync/atomic.CompareAndSwapUintptr runtime.sync_atomic_CompareAndSwapUintptr·f: undefined: sync/atomic.CompareAndSwapUintptr runtime.sync_atomic_StoreUintptr·f: undefined: sync/atomic.StoreUintptr runtime.sync_atomic_SwapUintptr·f: undefined: sync/atomic.SwapUintptr

[ianlancetaylor]

Thanks. I can recreate the problem. It's a bug in how the go tool generates the library name.

The workaround is: don't cd DIR and run "go install -buildmode=shared -linkshared". Instead, run "go install -buildmode=shared -linkshared DIR". The go tool is using the explicit argument to construct the library name. When you don't give it any argument, the go tool generates "lib.so". That then confuses the linker.

CC @mwhudson

[avdva]

Thank you for your assistance. I am really glad to be helpful for this project)

[mwhudson]

Oh right, this is sort of the same problem as #10473 then.

[rsc]

There's a clear workaround here. Better to use that for the 1.5 cycle. Thanks.

[gopherbot]

CL https://golang.org/cl/13921 mentions this issue.