Created attachment 316813 [details, diff] Patch for dev-lang/gprolog, alternative 1 The ebuild dev-lang/gprolog-1.40 installs its files to /usr/lib/gprolog-1.4.0/{bin,include,lib}. That's just upstreams default location. While this is not necessarily a bad thing (eg. useful for slotting), it causes the gprolog binaries not to be part of the search PATH. GProlog's Makefile tries to solve this by creating symlinks from /usr/bin to the real directory – but it just braindeadly creates the link '/usr/bin/*' -> '/usr/lib/gprolog-1.4.0/bin/*' (yes, literally!). Now, there are two possibilities to fix this problem: 1) Keep status quo and install the files to /usr/lib/gprolog-1.4.0, but create an /etc/env.d entry which adds /usr/lib/gprolog-1.4.0/bin to the PATH. See attached gprolog-path-1.patch. 2) Install the files directly to the /usr hierarchy, as everbody does. This makes the directory layout easier, but might be a problem if somebody wants to install multiple versions of gprolog in parallel (at the moment, there is only one version of it in Portage, though...). See attached gprolog-path-2.patch. I would personally prefer approach 2), but it doesn't really matter as long as it just works.
Created attachment 316815 [details, diff] Patch for dev-lang/gprolog, alternative 2
Thanks for spending some time having a look into this bug. A curiosity is that "ln -s $(BIN)/* ." used to work with earlier versions of portage/sandbox. It's now fixed in CVS. (Symlinks now correctly point to the gprolog binaries).
