On Wednesday, 17 September 2014 at 05:52:29 UTC, Chad Joan wrote:
--- 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).
If you're not using the slotted ebuild from:
https://bugs.gentoo.org/show_bug.cgi?id=481788
...you won't have that so file; only the version that links with
SDL 1.2. And if we look:
wyatt@Yue ~ $ ls -F -w66 /usr/lib/libSDL* |grep ttf
/usr/lib/libSDL_ttf-2.0.so.0@
/usr/lib/libSDL_ttf-2.0.so.0.10.1*
/usr/lib/libSDL_ttf.so@
Sure enough! I'd suggest pinging that bug because SDL2 isn't
going away any time soon.
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 ;)
While I certainly couldn't blame you for harshing on the dynamic
linker most days, this (surprisingly) isn't one of them. It's
innocent. Shocking, I know.
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
As it happens, this is almost exactly what actually happens:
http://unix.stackexchange.com/a/22999
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.
On Linux (and OSX?), at least, E_NOTOURPROBLEM. I possibly
recall there was some amount of hilarity related to this on
Windows, but that's an area where I Just Don't Care™.
-Wyatt
