How to figure out what's using CGo?

<p>I&#39;m writing an application, and have only just realised it&#39;s using CGo by accident. I purposefully looked for dependencies for things that I needed that didn&#39;t use CGo.</p> <p>I&#39;ve already found that the <code>user.Current()</code> function uses CGo, so I&#39;ve swapped that for MitchellH&#39;s package to do the same thing - yet when I run <code>go build</code> it still produces a dynamically linked binary.</p> <p>If I run with <code>CGO_ENABLED=0</code> then it does seem to work, but I&#39;m not totally sure. How can I tell what&#39;s causing it to use CGo?</p> <hr/>**评论：**<br/><br/>phildrip: <pre><p>Have you built with <code>CGO_ENABLED=0</code>? You only mention running with it.</p></pre>SeerUD: <pre><p>I have, and that does work and produce a statically linked binary. However, the first time I did that was before I had used MitchellH&#39;s library for getting the user&#39;s home directory.</p> <p>When using the built-in <code>user</code> package with <code>CGO_ENABLED=0</code> it still built perfectly fine, but when I tried to run the resulting binary I received the following error:</p> <blockquote> <p>user: Current not implemented on linux/amd64</p> </blockquote> <p>Given that I wasn&#39;t warned about that during the build process, it&#39;s now made me a little nervous that some other part of my application may fail, and I&#39;m just curious to know if there&#39;s something that will say something like:</p> <blockquote> <p>Package &#39;&lt;PACKAGE&gt;&#39; could use CGo, something may be broken, or not work as expected.</p> </blockquote></pre>Perhyte: <pre><p>If you&#39;re on a unix-like system, go to your main package folder and execute</p> <pre><code>go list -f &#34;{{if .CgoFiles}}{{.ImportPath}}{{end}}&#34; $(go list -f &#34;{{.ImportPath}}{{range .Deps}} {{.}}{{end}}&#34;) </code></pre> <p>from your terminal. (Alternatively, put package name(s) right before that last parenthesis with an extra space before it, then you don&#39;t have to go to the package folder)</p> <p>The <code>go list -f &#34;{{.ImportPath}}{{range .Deps}} {{.}}{{end}}&#34;</code> asks <code>go list</code> for a list of the current package and its dependencies, and those package names are then passed as parameters to a second <code>go list</code> to print only the packages in that list that use CGo (i.e. the ones that have any CGo files).</p> <p>If you don&#39;t have access to a *nix shell, you should be able to do the substitution manually by pasting the output of that second <code>go list</code> in the place of the <code>$(...)</code> in the first because that&#39;s the only unix-ism in the command.</p> <p>Note: If you want to specify build flags (for example <code>-tags netgo</code>) you&#39;ll need to pass them to both <code>go list</code> commands.</p></pre>Sphax: <pre><p>Don&#39;t you need the netgo tag too ? Not 100% sure but that&#39;s what I do </p></pre>SeerUD: <pre><p>From briefly looking, this seems to have changed since Go 1.5. </p> <blockquote> <p>The decision of how to run the resolver applies at run time, not build time. The netgo build tag that has been used to enforce the use of the Go resolver is no longer necessary, although it still works. A new netcgo build tag forces the use of the cgo resolver at build time. </p> </blockquote> <p>It sounds like if you use <code>CGO_ENABLED=0</code> then it&#39;ll just not be a problem.</p></pre>