Am Fri, 15 Nov 2013 01:01:34 +0100 schrieb Marco Leise <marco.le...@gmx.de>:
> Am Fri, 15 Nov 2013 00:03:42 +0100 > schrieb Marco Leise <marco.le...@gmx.de>: > > > Am Thu, 14 Nov 2013 21:35:22 +0100 > > schrieb Johannes Pfau <nos...@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. I guess most linux distributions will just choose one compiler and then compile everything with this compiler. (Probably not DMD because of OSS reasons) But I don't have a good or quick solution for this issue so I certainly won't complain about any working solution ;-)