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

[Marco Leise]

Am Fri, 15 Nov 2013 20:34:25 +0100
schrieb Johannes Pfau <nospam at example.com>:

> Am Fri, 15 Nov 2013 01:01:34 +0100
> schrieb Marco Leise <Marco.Leise at gmx.de>:
> 
> > Am Fri, 15 Nov 2013 00:03:42 +0100
> > schrieb Marco Leise <Marco.Leise at gmx.de>:
> > 
> > > Am Thu, 14 Nov 2013 21:35:22 +0100
> > > schrieb Johannes Pfau <nospam at example.com>:
> > > 
> > > > 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.
> > > 
> > > That explains why Haskell's Cabal is installing libraries with
> > > compiler AND library version in the file name :-/
> > 
> > That doesn't read too bad:
> > http://en.wikipedia.org/wiki/Rpath#GNU_ld.so
> > So -rpath basically just hints at the library location.
> > CMake has more or less direct support for it:
> > SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> > 
> > The other option would be to install a symlink foo.so into the
> > compiler specific lib directory that links
> > to /usr/lib/foo-dmd.so.X.Y that has an soname of "foo.so.X".
> > But I feel that would confuse the pants off of people.
> > 
> 
> The linux distributions will have to agree with this path schemes
> though. It's probably more a political problem, but still.
> 
> For example in debian using rpath is discouraged
> https://wiki.debian.org/RpathIssue
> 
> There's also another bad consequence of missing binary compatibility: If
> you have app A compiled with LDC and app B compiled with GDC and both
> app A and B depend on vibeD, mustached, dyaml then you'll have too keep
> copies of all those libraries for gdc and ldc.

Yes, making this possible is the reason I'm going through all
the trouble in the first place. Currently it is difficult to
keep these copies around and up to date if you want to test
different compilers and D versions with your code.
This should be handled by the package manager and some global
and per package variables that list the D versions to use.

> I guess most linux distributions will just choose one compiler and then
> compile everything with this compiler. (Probably not DMD because of OSS
> reasons)

Sure, but different distributions exist because some people
have other ideas of Linux. E.g. Gentoo has always been about
freedom of choice. And for us as developers it is always good
to be able to easily compile code with any of the D compilers,
including library dependencies. If you only had GDC or LDC you
couldn't test your D program with the upcoming beta of DMD.
Well, you could download it, but then you need to recompile
all D libraries that you need with DMD and make sure you don't
mess up the existing LDC/GDC installation of those libs.

> But I don't have a good or quick solution for this issue so I certainly
> won't complain about any working solution ;-)

That's what I wanted to hear!

-- 
Marco