Bugzilla Bug 156182

The ecl executable seems to have changed how it finds libecl.so since version
0.9h; I don't know what magic it used before (since the library is in the same
place), but now it seems to do the Right Thing and use standard dynamic
loading.  Adding an LDPATH=/usr/lib/ecl entry in /etc/env.d fixes the linking
problem mentioned in package.mask (unless that refers to a different kind of
linking problem...).

After that, it seems to work mostly as expected with just a few other minor
issues:
-The compile-file and c:build-program families of functions fail since they
look for their headers in /usr/lib/ecl (or /usr/lib64/ecl) for some reason; I
couldn't figure out exactly where they pull that path from, so I made a symlink
with: ln -s /usr/include/ecl /usr/lib/ecl/
and everything worked fine after that (even if it is a really ugly solution).
-More of an upstream thing, but the newer snapshots of slime in portage
(2.0.0.date and the cvs ebuild) are incompatible with this version of ecl (but
2.0 works fine).  I'll inquire about that one upstream probably.

fixed.