* 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haloe3de....@mid.deneb.enyo.de
