Where should D programs look for .so files on Linux (by default)?

[Chad Joan via Digitalmars-d]

--- The Problem ---

I was using Derelict to play around with SDL/OpenGL in D for a 
bit, and I was initially unable to do so because DerelictSDL2's 
search paths for .so files could not find libSDL2_ttf.so on my 
Linux distribution (Gentoo).

This seems quite solvable these days, so I entered an issue on 
DerelictSDL2's issue tracker.  As I typed away, it became 
apparent that this is probably something that the entire D 
community should care about: intelligent lookup of a system's .so 
files (or lack thereof) could have a profound impact on user 
experience for anyone on Linux using programs written in D.  Mike 
(aldacron) responded with a request to gather input from the D 
community at large, so here it is ;)

The original issue tracker is here:
https://github.com/DerelictOrg/DerelictSDL2/issues/28

--- One Solution ---

As an initial proposal, how about this:
1. Look in ./
2. Look in $LD_LIBRARY_PATH
3. Look in all directories listed in /etc/ld.so.conf
4. Look in a baked-in list of last-ditch fallback options. 
Although I'm sure better could be done, my current suggestion 
would look like this:
4a. ~/lib
4b. /usr/local/lib
4c. /usr/lib

This logic should probably end up in Phobos or somewhere suitably 
common, and revised as needed, so that all D programs can benefit 
from the community's research and experience on the subject.

As a data point: on my Gentoo box, the truly important step 
(usually) is to look in '/etc/ld.so.conf'.  My machine has a 
fairly comprehensive list in that file, and LD_LIBRARY_PATH 
doesn't have squat.

It may be desirable to first search folders or specific paths 
that are explicitly provided by the caller, and possibly skip the 
default search paths entirely if the caller insists.  I'm not 
sure how that would look, since the explicit path would probably 
be passed to a (non-Phobos) library-specific loading function 
(ex: DerelictSDL2.load(...)) before making its way to any 
community ordained logic.

In retrospect, I also have some reservations about looking in 
'./'.  I am not sure what the security implications are.  If 
there are no security concerns, then I, as both a developer and a 
user, would intuitively want D programs to look in ./ first 
(unless, perhaps, the program has an explicit search path 
defined, such as a packaged folder full of .so files, then 
/maybe/ those should go first).  As a developer, I might want to 
drop my program's .so/.dll files into the same directory as the 
executable, and I'd expect it to "just work". This is important 
whenever package managers can't be relied upon to deliver a 
correct version of the .so (ex: for obscure libraries), or can't 
be relied upon to release the program at all.  As a user, I 
sometimes want to replace .so/.dll files with different versions 
(ex: if the developer's version links to symbols or is compiled 
with features that don't exist on my system and are not strictly 
needed by the program).



Is this a reasonable approach, or is there a more appropriate way 
to handle this search?