On 16 Nov 2015 8:15 am, "Marco Leise via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > Am Thu, 12 Nov 2015 10:26:54 +0000 > schrieb Marc Schütz <schue...@gmx.net>: > > > I'm interested in this topic, too. Has there been a conclusion as > > to distributions should install includes and libraries of > > different compilers (and versions), which sonames to use, etc? > > The shared library topic was too hot back then and DMD I think > is still the only compiler which does shared linking out of > the box in a default installation. If you ask about only > Phobos, I would just use the soname provided by upstream: > libphobos2.so.0.69.1 > libphobos2.so.0.69 -> libphobos2.so.0.69.1 > libphobos2.so -> libphobos2.so.0.69.1
Another thing to note would be that gdc names the library libgphobos2 to avoid conflict. I suspect ldc does the same, or if it doesn't, would have to be patched locally to. > (The convention for the first symlink may differ per > distribution). These files should be installed into your > system's shared library lookup path, so that dynamically linked > executables can be run on other systems. For example you could > compile a program on your machine and ssh copy it to a remote > server running in a low memory VM where compilation would be > impossible. If that use case works, you are doing it right. ;) > > As for additional libraries, you are in trouble. Not only is > it common to have 32-bit+64-bit libraries, but we also have > ABI differences between three popular D compilers and > potentially each new release of Dlang. So if you ask where to > put libraries I'd say somewhere, where they are separated by > architecture, compiler and compiler version. While this scheme > works for Gentoo, I had to bend the rules quite liberally to > make it happen and these packages have no chance of getting > into the main tree. > > The alternative is to always use one compiler (e.g. DMD) and > update all libraries in sync with a DMD update. Then you can > install these libraries to the standard path as well. This is > practically what is done in the C/C++ world. ABI breakages are > far and in-between there but do happen like just now with the > change to use a namespace prefix for the mangling of "string". > There should be ways to catch ABI changes in the build or test process. Maybe I'm misremembering something though. :-) There should be a degree of ABI compatibility between releases for plain static functions - assuming that we add no more properties to the language. That leaves what breaks the most in moving to a new version are template instantiations, no?