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

Open
upsampled opened this Issue Mar 5, 2018 · 4 comments

Comments

Projects
None yet
5 participants
@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)?

GOARCH="amd64"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build706877829=/tmp/go-build -gno-record-gcc-switches"
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"

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 libpa.so 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 libpa.so -x -a ./libpa produces the expected libpa.so 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

@andybons

This comment has been minimized.

Member

andybons commented Mar 7, 2018

@ianlancetaylor

This comment has been minimized.

Contributor

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 foo.so. 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.

@paride

This comment has been minimized.

paride commented Jul 7, 2018

@ianlancetaylor Is it really unpredictable? The installation path makes sense to me. My use case is https://github.com/google/fscrypt, 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/github.com/google/fscrypt/pam_fscrypt.a. 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.

@ianlancetaylor

This comment has been minimized.

Contributor

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