Here is how to see the transitive set of packages P depends on.
go list -f $'{{range $f := .Deps}}{{$f}}\n{{end}}' P | sort
On Fri, Mar 31, 2017 at 6:49 AM, Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Mar 31, 2017 at 5:00 AM, Basile Starynkevitch
> <bas...@starynkevitch.net> wrote:
> >
> > I don't understand as much for the Go compiler, using the go tool. In
> > particular I have a very incomplete understanding about :
> >
> > what is the exact structure and content of a Go compiled package file?
> > Apparently it is some ar archive with __.PKGDEF & _go_.o members. Why?
> What
> > are appropriate tools to inspect these package files?
>
> The Go object file format is subject to change. A Go package is
> normally compiled into an archive file that holds a Go object file
> plus object files for any non-Go code included in the package. The Go
> object file has an extension of ".o" but is in a private format used
> only by Go. You can examine the contents of a Go object file using
> `go tool nm` and `go tool objdump`. Go uses a private format because
> building a Go program requires a number of data structures to be built
> at link time, and historically it has seemed more efficient to use our
> own format rather than try to shoehorn all Go-specific information
> into an ELF file.
>
> > sometimes, it looks like the Go compiler is using HTTP requests to fetch
> > source code (e.g. from github). When does that happen? What kind of HTTP
> > requests?
>
> The Go compiler never makes HTTP requests. The `go get` subcommand
> makes HTTP requests. You can see the docs for `go get` by running `go
> help get`.
>
> > where is the output going for a given go command?
>
> It depends. The main command that generates output is `go install`,
> and it stores the output under $GOROOT/pkg.
>
> > What is the exact effect of -linkshared and of -buildmode=shared ?
>
> The -buildmode=shared option means that the Go linker will build a
> shared library suitable for use with -linkshared. This must normally
> be used with `go install` so that the shared library will be placed
> where the Go linker can find it.
>
> The -linkshared option means that the Go linker will look for shared
> libraries built with -buildmode=shared instead of linking those
> packages in directly.
>
> Obviously there are other effects on how the code is compiled and
> linked but I think you will need to ask more specific questions.
>
> > How does the compilation works?. I have the intuition (perhaps wrongly)
> that
> > in many cases only the package and the import statements are parsed in
> .go
> > files? When does that happens, and when is the file entirely parsed?
>
> That never happens. I'm not sure what you are thinking of.
>
> > What is the effect of import and what exactly does the import path means
> ?
>
> When running the go tool, the effect of import is to cause the go tool
> to build the imported package before building the package that imports
> it. When running the Go compiler, the effect of import is to tell the
> compiler to look for the already-built imported package and collect
> information about the exported symbols. When running the Go linker,
> the effect of import (as represented within the object file) is to
> tell the linker to look for the already-built imported package and
> link it into the generated executable or shared library. The effect
> of -linkshared is on the Go linker: it tells the linker to generate a
> reference to the shared library rather than to link in the library.
>
> > What exacty is the import comment? And custom imports? Their relation
> with
> > -linkshared?
>
> See "Import path checking" in `go help import`. Import comments and
> custom imports have no relation with -linkshared.
>
> > I badly miss some equivalent for go of the -H option for gcc. In my
> dreams,
> > I would like some -show option which would display the complete file
> path of
> > successfully read files, and the complete URL of successful HTTP GET
> > requests, and the complete file path of successfully written files. If
> that
> > is easy to implement (and I believe it is), could someone explain me what
> > files and functions of the compiler should I patch?
>
> When discussing it's first necessary to understand that the go tool is
> not the Go compiler. The go tool invokes the Go compiler. You can
> always see exactly what commands the go tool is running by using the
> -x option.
>
> There is no reason to add a -H option to the Go compiler. When
> compiling a package P, the compiler reads exactly and only the
> packages imported by the .go files in P.
>
> You can use the go tool to see the set of files imported by P:
> go list -f '{{.Imports}}' P
> That will show the list of packages directly imported by P. To get a
> list of transitive imports you will have to run the command for each
> of those imported packages, etc.
>
> For exact HTTP GET requests and so forth, use `go get -x`.
>
> 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.
>
--
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.
