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

[Johannes Pfau]

Am Thu, 14 Nov 2013 20:02:46 +0100
schrieb Marco Leise <Marco.Leise at gmx.de>:

> Am Thu, 14 Nov 2013 19:11:17 +0100
> schrieb "Dejan Lekic" <dejan.lekic at gmail.com>:
> 
> > On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:
> > >
> > > I don't want to be limited to one installation of Phobos.
> > > That's why there is no "none" option. It is required to have
> > > e.g.:
> > > /usr/include/dlang/dmd-1.076/druntime
> > > /usr/include/dlang/dmd-2.063/druntime
> > > /usr/include/dlang/dmd-2.064/druntime
> > > /usr/include/dlang/ldc-0.12.0/druntime
> > > and
> > > /usr/lib/dlang/dmd-2.063/phobos.a
> > > /usr/lib/dlang/dmd-2.064/phobos.a
> > 
> > You should be clearn that you were asking about where to put 
> > Phobos, not various D import files (from other D packages).
> 
> Both actually. This was just an example with no bike-shedding
> potential.
> 
> > For Phobos import path, again, I would go for 
> > /usr/include/d/{dmd*|ldc*|gdc*}
> > 
> > For the libraries, I also follow the same approach ArchLinux 
> > packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
> > them all in the /usr/lib or /usr/lib{32|64} depending on distro...
> 
> In fact there is a need for it as soon as you install them once
> for each compiler. And that's where I want to go.
> Alternatively suffixes could be used, but that makes it more
> difficult to find the correct library name. So I went for
> sub-directories.
> 

AFAIK you can't put shared libraries into a different folder.
The runtime linker must be able to find the libraries so the folders
have to be registered in ld.so.conf. But ld 'virtually merges' all
directories so you still can't have libraries with the same name &
version in different folders. There are some tricks (rpath,
LD_LIBRARY_PATH) but this won't work well in a large scale scenario.

In the end all D compilers have to produce ABI compatible
shared libraries. The runtime implementation may be different, but the
ABI has to match. Unfortunately ABI compatibility is still in a distant
future but there's no other way to solve the library issue.