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