./configure scripts of many packages will pick headers/libraries installed under /usr/local which may result in core packages being run-time dependant on non-system stuff. Reproducible: Always Steps to Reproduce:
i dont really see how this is possible
I agree, this is not really possible unless we make some really dirty hacks that will affect the system in general, not only portage. The only possible way is to "fix" the configure scripts of the affected packages, but that's not a portage task.
Er? At the very list, before installing anything executable (including .so libs) it should be verified that ldd on that object doesn't point to anything except system locations (similar to as now anything trying to remove a file during installation triggers the fatal SANDBOX error). Regarding the "really dirty hacks that will affect the system in general": it shouldn't be more dirty than e.g. esystem-wide usage of distcc or host-type specification. Both compiler and linker provide flags for specifying search paths explicitly. E.g. -nostdinc -isystem /usr/include.
Then please provide patches.
Actually, the simplest solution would be to install gcc configured e.g. with --with-local-prefix=/usr/gcc-local. On all classic Unix systems, compilers by default don't look at /usr/local/[lib,include], and this is the RIGHT thing, IMHO. Regarding patches: I don't think it's especially smart to request users to patch bugs. I'd expect developers do it better/faster. From what I can observe, though (I'm quite a newbie to Gentoo), one should modify the "prepall" script to add after prepallstrip another one, say prepallldd, similar to prepallstrip. At the core: ldd $object |grep -q /usr/local and check for $?. If 0, abort the installation.
You call it a bug, I call it a new feature. I'm pretty sure some people want things linked against libs in /usr/local.
If you mean things added _locally_, i.e. binaries in /usr/local/bin etc - sure, and I'm among these people - but that's what -I and -L flags are for. On true multi-user systems some users install things in $home/[lib,include,bin,...], which doesn't say gcc should automatically add these dirs to its search paths. But system stuff should _never_ be dependant on /usr/local (which often resides on a separate partition, sometimes - mounted over NFS). Otherwise, one can easily end up with a broken system after a reboot.
BTW, developers are users as well. The development team welcomes all patches as it's less timeconsuming :)
if we remove /usr/local/lib from /etc/ld.so.conf, would that fix this ?
Nope. The problem with ld.so.conf is that 1) /usr/local/lib is really needed if people install things outside the system. Removing it by default from ld.so.conf will result in FAQs and then everybody will add the path anyway (like it happens all the time with e.g. RH) 2) and once something is in ld.so.conf, there is no way to dynamically remove it (as opposite to the compiler/linker search stages 3) further, some smart configure's check whether libraries found in /usr/local/lib are loadable and if not, pass -R/usr/local/lib to the linkage stage to hardcode the path.
If someone is really up to driving themselves insane... they could read deny /usr/local/ using sandbox. (Have to hack sandbox, I think. Not sure it handles this particular kind of read heirarchy.)
This isn't really doable, aside from doing dirty sandbox hacks (which aren't preferable). Configure scripts check /usr/local on their own typically...
(In reply to comment #10) > Nope. The problem with ld.so.conf is that > 1) /usr/local/lib is really needed if people install things outside the system. Removing it by default from ld.so.conf will result in FAQs and then everybody will add the path anyway (like it happens all the time with e.g. RH) > 2) and once something is in ld.so.conf, there is no way to dynamically remove it (as opposite to the compiler/linker search stages > 3) further, some smart configure's check whether libraries found in /usr/local/lib are loadable and if not, pass -R/usr/local/lib to the linkage stage to hardcode the path. > Evgeny, do you have any proper solution or workaround for this issue? Basically my problem is following: I'm unable to build python and php with readline support because I have old custom readline of v4.3 installed in /usr/local/lib used by gqlplus (which I built manually). Hence python and php (and as I understood entire system) uses this old lib instead of using latest one from /usr/lib. Many thanks for any help.
Found the workaround by myself (may be will help somebody else) It is possible to override standard library paths for ld during emerge through LDFLAGS. In my case: LDFLAGS="-L/lib" emerge -v php in this case ld will pick up libs from /lib first instead of /usr/local/lib
