the multilib.bash code hardcodes: ES_VALID_MULTILIB_DIRS="lib lib32 lib64" this list isn't complete for all targets (libx32 comes to mind), nor does it handle the random extended dirs that some targets can get into (cpu-specific multilibs) later, the code greps /etc/ld.so.conf to validate these paths. that is incorrect for two reasons: - the paths could be included indirectly with the "include" directive - the lib paths being listed in ld.so.conf at all is not a requirement and may be omitted at runtime in looking at all the current consumers (env, opengl, php, postgresql), i'm not sure why we need this hardcoded list at all. the modules really only work if the libdirs are available, so the current fallback could just as easily be the only code we have in there: libdirs=( "${EROOT}"/lib* ) libdirs=( "${libdirs[@]##"${EROOT}"*(/)}" ) this doesn't handle my point about cpu-specific multilib dirs in subdirs (e.g. /usr/lib/foo/xxx), but i think most of the tree will be broken if we try supporting that, so we can probably punt it for now ...
The current behaviour originates from bug 114274. (In reply to comment #0) > [...] the current fallback could just as easily be the only code we have in > there: > > libdirs=( "${EROOT}"/lib* ) > libdirs=( "${libdirs[@]##"${EROOT}"*(/)}" ) Generally, I'm fine with this. But maybe some sanity check should be added? Some sysadmins do strange things (I've seen /lib.old and similar on people's systems). Could we add libx32 to ES_VALID_MULTILIB_DIRS and use that list for filtering?
"lib.old" would only matter if it contained the additional paths that the eselect modules were searching for. in the "lib.old" case, that probably isn't too unlikely if it's just a `cp -a lib lib.old`. i'd like to get away from having to hardlist the valid ABI dirs anywhere, but unless eselect became aware of targets/toolchains/ABIs/etc..., that probably is the best tradeoff -- (1) add libx32 (2) do a libdir glob and filter results.
<http://sources.gentoo.org/cgi-bin/viewvc.cgi/eselect/trunk/libs/multilib.bash.in?r1=864&r2=863&pathrev=864>
Fixed in eselect-1.3.1.
