Re: [RFC] Go (golang) packaging
On 01/01/13 16:14, Michael Stapelberg wrote:
> Hi Paul,
>> Support dynamic linking? That would avoid the whole rebuild-the-world
>> thing that statically-linked languages have.
> Only when not using the “official” compiler (gc), e.g. gccgo has support
> for dynamic linking.
Where does gccgo look for Go sources (src)?
Where does gccgo look for Go "static libraries" (pkg)?
Where does gccgo look for Go dynamic libraries? (Presumably the same
places where gcc looks for C dynamic libraries?)
>> Not require the full source code for libraries? C and other libraries
>> only require the interface headers.
> AFAIK not, but I will add this to the list of questions I want to ask on
> the Go mailing lists.
If a significant amount of code is going to be written in Go, it would
be useful to understand the classes of source change that do and don't
constitute an API break (well-understood for C, somewhat well-understood
for C++), and the classes of source change that do and don't constitute
an ABI break for gccgo.
Michael additionally wrote:
> I propose to patch
> Go in Debian so that it always appends /usr/lib/gocode when reading
> the list of paths from $GOPATH.
Add /usr/local/lib/[$TUPLE/]gocode as "more important than"
/usr/lib/[$TUPLE/]gocode, perhaps? That's how /usr/local usually works
in Debian.
> Essentially, I currently believe that multi-arch does not make sense
> for go, since we are only dealing with static binaries.
For multi-arch runtime libraries (in-scope for wheezy), sure, it's not
useful because there are no runtime libraries.
For multi-arch headers and development libraries (not formally in-scope
for wheezy, but some simpler packages already support it, and it's
likely to be a goal for jessie), it's useful to be multiarch so an
i386/amd64 system can have both golang-libhello:amd64 and
golang-libhello:i386, so that it can build both helloworld:amd64 and
helloworld:i386.
If golang has its own partial solution for multiarch but that solution
is actually insufficient for what we need (linux_arm for both armel and
armhf, etc.) and upstream are unwilling to make it sufficient, then I
don't see anything particularly wrong with
/usr/lib/arm-linux-gnueabi/golang/linux_arm/libhello.a. Sure, it's
redundant, but it works...
[Dmitrijs wrote:]
>> /usr/lib/gocode/ for sources
/usr/[local/]share/gocode if they're arch-indep, surely? Or if they
*can* vary by arch but usually don't (like C headers),
/usr/local/lib/$TUPLE/gocode:/usr/local/share/gocode:/usr/lib/$TUPLE/gocode:/usr/share/gocode
or something?
> Furthermore, the package names should be e.g. “golang-codesearch” for
> the library code.google.com/p/codesearch (and of course just
> “codesearch” for the binaries).
Should the package with the "headers" and "static library" be
golang-codesearch-dev or something, in the hope that when Go grows the
ability to build dynamic libraries, the dynamic libraries can be called
golang-codesearch?
> For cross-compiling, it doesn’t matter which pre-compiled packages
> you have installed (e.g. linux_amd64) because the .go source files
> are shipped, too. go build will just re-compile the libraries then:
How "cheap" is recompiling everything? If it's sufficiently cheap, you
could just ship complete source and ignore the "static libraries"
entirely; or if it isn't, you'll benefit from proper multiarch.
S
Reply to: