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

Jump to bottom

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

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

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

upsampled opened this issue Mar 5, 2018 · 4 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unplanned

Comments

@upsampled
Copy link

upsampled commented Mar 5, 2018 •
edited

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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 7, 2018
@andybons andybons added this to the Go1.11 milestone Mar 7, 2018
@andybons
Copy link
Member

andybons commented Mar 7, 2018

/cc @ianlancetaylor

@ianlancetaylor
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels Jul 6, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jul 6, 2018
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 6, 2018
@paride
Copy link

paride commented Jul 7, 2018 •
edited

@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
Copy link
Contributor

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."

@skazi0 skazi0 mentioned this issue Nov 24, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@andybons @ianlancetaylor @paride @gopherbot @upsampled