First of all, the libraries in question (libc.so, which imports the
others), are essentially guaranteed to exist on just about any linux
machine, so you should be fine if those are your app's only needed dynamic
libraries. In darwin (Mac OS X) not only are the equivalent libraries
(libSystem.B.dylib, and its dependencies) guaranteed to exist, but AFAIK,
it is impossible to find equivalent static libraries. On Windows, the OS
doesn't provide a single statically linked library at all, so all binaries
must be dynamically linked there. Essentially, if your only dynamic links
are against system libraries, which is the case for the net package
(imported by net/http), then there isn't a dependency issue as the library
you need should always be there.
As far as your second question goes, go1.1 suports what is called
"external" linking, where the system linker is invoked after the
go-provided one (6l, 8l, or 5l) to actually perform the final link, and
thus supports the full range of features needed to statically link most
code properly. As an example, the SQLite package athttp://code.google.com/p/go-sqlite
provides the source code for SQLite and
statically links the produced library into your binaries, something that
couldn't be done in go 1.0 with the "internal" linker. The "external"
linking method should be enabled automatically if you use CGO, although a
recent bug has been discovered in the binary distribution of go1.1.1 on
darwin (https://code.google.com/p/go/issues/detail?id=5726). Note: the
"external" linking mode doesn't enforce static linking, it is just better
supported; Go will still link to dynamic libraries if any are specified by
the cgo arguments, and in the case of the above, there may not be
statically linked versions of the libraries it uses.
It is possible to build the go environment without using CGO at all; by
setting CGO_ENABLED=0 before building go from source. The packages that use
cgo in the std library (net and os/user) will still build, but have limited
functionality then. For the net package, name resolution (net.Lookup*) is
normally handled by cgo code because it will then use the same C code that
every other program on the system uses and thus produce the same results.
If cgo is disabled, a mechanism written in go will be used instead, and it
will most likely produce different and fewer results. For os/user, the
non-cgo code always returns an error.
A recent update in tip adds the build tag netgo, which builds the net
package to not use cgo without disabling cgo entirely, or needing to
rebuild go. So you can build you program using the following command: "go
build -tags netgo -a", and it will build your binary, and rebuild all
needed packages with the netgo build tag set. You need the build all flag
"-a" since the go tool doesn't (yet) rebuild a package if it was built with
different build tags than are currently set.
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 email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.