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.
