Skip to content
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/go: installed c-shared libraries receiving ".a" suffix on Linux #24253

upsampled opened this issue Mar 5, 2018 · 4 comments

cmd/go: installed c-shared libraries receiving ".a" suffix on Linux #24253

upsampled opened this issue Mar 5, 2018 · 4 comments


Copy link

@upsampled upsampled commented Mar 5, 2018

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

go version go1.9.4 linux/amd64

Does this issue reproduce with the latest release?

Yes. Reproduced with 1.10

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

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build706877829=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go install -buildmode=c-shared -x -a ./libpa

libpa contains a a C library declared in a main package.

What did you expect to see?

I expected the output file to be labeled indicating it was a shared object

What did you see instead?

The output was labeled libpa.a indicating an archive file, but in actuality it was a shared object file.

file $GOPATH//pkg/linux_amd64_shared/<pkg dir>/libpa.a
libpa.a: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=31934079c8d80546780a304c28421f0d8228c9a4, not stripped

Additional Information

  • go build -buildmode=c-shared -o -x -a ./libpa produces the expected output. This is how .so files are generated in cshared_test.go.
  • go install -buildmode=c-archive -x -a ./libpa produces an archive file correctly named libpa.a
  • init.go leaves the cfg.ExeSuffix empty for Linux machines when the c-shared option is selected (sets it to ".a" for c-archive).
  • Passing GOEXE=".so" does not appear to overwrite the cfg.ExeSuffix.
@andybons andybons added this to the Go1.11 milestone Mar 7, 2018
Copy link

@andybons andybons commented Mar 7, 2018

Copy link

@ianlancetaylor ianlancetaylor commented Jul 6, 2018

Note that it doesn't make a great deal of sense to use go install -buildmode=c-shared. The expectation is that people will use go build -buildmode=c-shared -o The only point of using -buildmode=c-shared is to use the shared library somewhere, and using go install without -o will put the shared library in a relatively unpredictable place.

I'm fine with changing the default installation name but I don't see that it will make any difference in practical use.

Copy link

@paride paride commented Jul 7, 2018

@ianlancetaylor Is it really unpredictable? The installation path makes sense to me. My use case is, of which I maintain the Debian package. If I run go install -buildmode=c-shared ./pam_fscrypt, the shared library gets installed as ~/go/pkg/linux_amd64_shared/ This is not its final destination of course, but it's good enough for me: the packaging scripts will then take care of the rest. (Edit: when using the Debian Go packaging helpers that's not actually the folder, but this is not important now.)

The fact that the library is named .a and not .so is not really a problem, but it is a bit confusing and feels "wrong". I think the default should be changed.

I could use go build as you suggest, but I'd had to handle it as a special case, and it is not currently supported by the Debian Go packaging tools.

Copy link

@ianlancetaylor ianlancetaylor commented Jul 8, 2018

I want to make clear that the go tool does not in any way promise that the path you mention is the one that will be used by future releases. It is already the case that that path is not the one used on every platform. I suppose that that is what I mean by "unpredictable."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants