CC @thanm @cherrymui @jeremyfaller

Marking as a release blocker for 1.15. We should investigate this and decide whether it is a problem that needs to be addressed for 1.1.5

Sorry, I cannot reproduce it on my machine:

$ go install -buildmode=shared -linkshared -pkgdir /tmp/lib std
$ go build -buildmode=pie -linkshared -pkgdir /tmp/lib hello.go 
$ file hello
hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b2e8af86bc78040632dfe47c792077a16659905d, for GNU/Linux 3.2.0, not stripped
$ ldd hello | grep libstd
	libstd.so => /tmp/lib/libstd.so (0x00007ffa3ff33000)

The generated binary is dynamically linked and linked against libstd.so.

Have you checked the executable file size?

despite ldd's output,

When I build hello world shared linked with 1.14.6 the size is 19 KB
with 1.15rc1 it is 4.8M if I use trimpath and ldflags; without them it is 9.4 MB

It seems the file also contains statically linked modules, try the same on 1.14.6 and compare executable file sizes and content of a simple hello world.

When I build statically the size is 2.3 MB

To the contrary the shared executable must be smaller in size

@kiap , just the clarify, can you state the exact problem you're seeing more clearly? It's not clear from your original bug report. Is it specifically that the shared linkage executable is significantly larger than it used to be, indicating the linker included a lot of things it shouldn't have? Are you seeing problems besides the size? (When you say it "generates incorrect code", that suggests a crash or panic when you try to run it.)

Change https://golang.org/cl/244839 mentions this issue: cmd/link: don't mark shared library symbols reachable unconditionally

Thanks for the note about the size. It is not that we linked in a static copy, but we accidentally put a large number of symbols into the dynamic symbol table.