[Poll] On Linux, what should we commonly use as sub-directory name for D?

[Iain Buclaw via Digitalmars-d]

On 16 Nov 2015 8:15 am, "Marco Leise via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> Am Thu, 12 Nov 2015 10:26:54 +0000
> schrieb Marc Schütz <schuetzm at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20151116/dbd0be9c/attachment-0001.html>