On Mon, Jan 14, 2019 at 3:26 PM <twpa...@gmail.com> wrote: > > Whether CGO is enabled or not affects how reliable certain standard library > functions are. For example, os/user.LookupGroupId is untrustworthy if CGO is > not enabled (example 1, example 2). > > I can use build flags and two separate source files to determine whether CGO > is enabled or not, for example in this commit. > > This feels like it should be part of runtime, like runtime.GOOS and > runtime.GOARCH. > > Is there a better way to determine whether CGO is enabled?
Build tags are the best way. Although it's true that the use of cgo affects of a few standard library functions, it's not remotely as fundamental as GOOS and GOARCH. There is a way to check--via build tags--so I'm not sure we need another mechanism. 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.
