On 27/08/13 15:57 -0400, Matthew Miller wrote:
I've been asked to help package / review a project written in Go. Since the
language is new, we don't have packaging guidelines (unless I've missed
them!), and I'm a Go newbie myself, so I'm left with some questions.
The first question I have is over the location of packages -- the library
modules. The ones that are part of golang are under
%{_libdir}/golang/src/pkg. Should third-party packages go alongside, or
% elsewhere?
There was a good start to this conversation had at Flock a couple of weeks ago. Thankfully other distributions have put a lot of thought into this as well, but there are a number of things that I feel we can handle in a very developer/user enabling way. Libraries of golang are basically src only, but having the *.a available are very nice. The thing that I've been grappling with lately, is that the *.a are not arch dependent. Due to the way the golang compilerworks, any host can compile for any end target. So by setting GOROOT to be in %{_libdir}, it is causing an arbitrary
BuildArch enforcement. _only_ for executables, is the final build arch specific. (e.g. if you set GOOS="windows" GOARCH="386" you can compile a *.exe, even if you can not execute it on the host that compiled it) So I've been working with Adam Goode and Adam Miller on a more flexible layout that would have libraries be noarch, and have sub packages for the various ARCHs *.a files, so you could pull in only the ones needed for a final binary executable. There is a bit of work needed, and I'm excited to work on it, while balancing my other work. For a recent tool, I packaged up a single library, that could be a current example of getting libraries packaged, but not where I want to get to. First a non-arch dependent way to handle the $GOROOT/pkg and $GOROOT/src agoode had tried symlinks, but some "magic" in the build had caused a broken install, so he reverted that.
Also it appears that Go programs compiled with the canonical golang are statically linked (http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary). Gccgo supports dynamic linking, but I'm not sure about compatibility issues.
The final binaries are static (Not different than haskell or ocaml), unless something uses 'cgo' which causes the resulting binary to have dynamic links to only that library. As for gccgo, it does compile to dynamic, but the GOROOT and GOPATH are not respected, so it's currently an exercise of the user to get their -I<path> flags setup for the imports of their project. Take care, vb
Attachment:
pgpinVHg1GRx7.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
