Re: Go (golang) packaging, part 2
* Michael Stapelberg:
> Hilko Bengen <bengen@debian.org> writes:
>> This is a pity for those of us who don't really subscribe to "get
>> everything from github as needed" model of distributing software.
> Yes, but at the same time, it makes Go much more consistent across
> multiple platforms.
Apparently, upstream's idea about the role of library code does not
really match the ideas that have been built into Debian and other Linux
distributions. This has happened before: Ruby (1.8, 1.9, ironruby,
rubinius, etc.), Java (we have multiple JRE implementations, Maven),
even Perl (perlbrew, local::lib, etc.) and will happen again.
This in itself is not a problem. We jsut have to figure out where the
diverging ideas are enscribed (I guess: primarily the "go" tool that was
introduced with Go 1.0) and see if we can tweak them to a compromise
that does not cause surprise and confusion.
>> Since one of the stated goals of the Go language and also the golang
>> compiler are fast builds: How about using the Emacs / Common-Lisp /
>> Python approach: Ship only source files in the .deb packages and build
>> object files during post-install?
> What advantage would that have? It won’t change the fact that we will
> only distribute Go libraries for building Debian binary packages.
Architecture: all packages.
>> How does gccgo fit into this picture, apart from the problem that object
>> files generated using gccgo are not compatible with those generated
>> using golang-go?
> I tried to explain that one cannot use gccgo to create dynamically
> linked shared libraries from Go libraries. At least not at the moment.
> All it can do is dynamically linked executables.
I drew a different conclusion from Ian's messages the thread you
mentioned (see the quotes below). Apparently, one *can* build shared
libraries using gccgo, but they are not currently usable using dlopen().
My impression was that this means that regular use of shared libraries
*is* possible with gccgo. And, indeed, my attempts at building
codesearch using gccgo was sucessful -- with the sparse, index, and
regexp packages compiled as shared libraries.
Ian just recommends against using shared libraries pretty much for
"consistency" reasons.
Cheers
-Hilko
* Ian Lance Taylor:
> The gccgo compiler is just like gcc. To build a shared library:
>
> gccgo -shared -o lib.so file.go
>
> There is no way to use the go tool to build a shared library.
(http://article.gmane.org/gmane.comp.lang.go.general/81686)
* Ian Lance Taylor:
> When using gccgo you can create and use shared libraries. Loading new
> code via dlopen doesn't really work; the Go initialization code for
> the dlopen'ed shared library will not be run.
(http://article.gmane.org/gmane.comp.lang.go.general/81567)
* Ian Lance Taylor:
> I don't really recommend providing packages as shared libraries even
> when using gccgo, it's not what Go programmers expect.
(http://article.gmane.org/gmane.comp.lang.go.general/81687)
Reply to: