Re: Go (golang) packaging, part 2
* Hilko Bengen:
> 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.
The problem with shared libraries in Go is that the API guarantee for
Go itself allows changes which break the shared library ABI, such as
adding struct fields (thus changing struct sizes and offsets). Sizes
and offsets are compiled directly into the code, without a relocation.
Even with shared libraries, we will have to recompile all dependent
packages in many cases.
This binary compatibility issue was addressed in the Java front end,
which had similar issues.
This is not unlike C or C++, of course, but some library authors there
have a more stringent attitude towards ABI compatibility and build API
change guidelines based on that. (Technically, we even have to
recompile all library packages when we make major changes to eglibc
because the static libraries are tied to a very specific eglibc
version because the symbols aren't bound to versions at that point.
So we probably shouldn't complain to loudly about other languages not
getting this completely right.)
Fedora hasn't got a solution for this, either, FWIW. OpenSUSE seems
to have support in their build infrastructure for soname bumps, which
could be used for this as well.
Reply to: