Thank you, I understand the situation mostly.
> Before that change, newosproc0 was used when code built with -buildmode=c-archive did not use cgo. Is there any use case for shared libraries that don’t have exported functions? Hiroshi Sent with Unibox > On Jul 19, 2017, at 7:40 AM, Ian Lance Taylor <i...@golang.org> wrote: > > > On Mon, Jul 17, 2017 at 8:51 AM, 井岡裕史 <hirochacha...@gmail.com> wrote: >> >> >> >> >> >> c-share and c-archive enforce external linking. >> https://github.com/golang/go/blob/504deee6088c2448fc3e91c94a1ba69ec92fb7ef/src/cmd/link/internal/ld/config.go#L191-L196 >> >> >> I think that external linking always use runtime/cgo because of following >> line. >> https://github.com/golang/go/blob/504deee6088c2448fc3e91c94a1ba69ec92fb7ef/src/cmd/link/internal/ld/lib.go#L459-L464 >> >> >> So, I still cannot find any possibility that newosproc0 will be called. >> > > > > > I think that is a bug in https://golang.org/cl/28971. The c-archive > build mode does not actually require external linking. The c-archive > build mode does not invoke the linker at all, so the choice between > internal and external linking is somewhat irrelevant. > > > Before that change, newosproc0 was used when code built with > -buildmode=c-archive did not use cgo. > > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
