Re: [go-nuts] What's the best way to detect if CGO is enabled?

[Ian Lance Taylor]

On Mon, Jan 14, 2019 at 3:26 PM  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.

[go-nuts] What's the best way to detect if CGO is enabled?

[twpayne]

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?

Cheers,
Tom

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