|Summary:||/usr/local/include and /usr/local/lib should be explicitly excluded when executing emerges|
|Product:||Gentoo Linux||Reporter:||Evgeny Stambulchik <fnevgeny>|
|Component:||[OLD] Core system||Assignee:||Portage team <dev-portage>|
|Package list:||Runtime testing required:||---|
Description Evgeny Stambulchik 2004-03-29 06:27:48 UTC
./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:
Comment 1 SpanKY 2004-03-29 12:02:00 UTC
i dont really see how this is possible
Comment 2 Marius Mauch (RETIRED) 2004-03-29 15:51:45 UTC
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.
Comment 3 Evgeny Stambulchik 2004-03-30 04:54:31 UTC
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.
Comment 4 Marius Mauch (RETIRED) 2004-03-30 05:21:17 UTC
Then please provide patches.
Comment 5 Evgeny Stambulchik 2004-03-30 06:00:52 UTC
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.
Comment 6 Marius Mauch (RETIRED) 2004-03-30 06:40:43 UTC
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.
Comment 7 Evgeny Stambulchik 2004-03-30 06:56:14 UTC
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.
Comment 8 Sven Vermeulen (RETIRED) 2004-03-30 08:17:10 UTC
BTW, developers are users as well. The development team welcomes all patches as it's less timeconsuming :)
Comment 9 SpanKY 2004-03-30 10:07:12 UTC
if we remove /usr/local/lib from /etc/ld.so.conf, would that fix this ?
Comment 10 Evgeny Stambulchik 2004-04-01 04:49:54 UTC
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.
Comment 11 Nicholas Jones (RETIRED) 2004-04-11 00:23:37 UTC
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.)
Comment 12 Brian Harring (RETIRED) 2005-02-28 00:25:32 UTC
This isn't really doable, aside from doing dirty sandbox hacks (which aren't preferable). Configure scripts check /usr/local on their own typically...
Comment 13 Viacheslav Gagara 2009-08-28 06:50:57 UTC
(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.
Comment 14 Viacheslav Gagara 2009-08-29 06:41:49 UTC
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