Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 46108 - /usr/local/include and /usr/local/lib should be explicitly excluded when executing emerges
Summary: /usr/local/include and /usr/local/lib should be explicitly excluded when exec...
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-29 06:27 UTC by Evgeny Stambulchik
Modified: 2009-08-29 06:41 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 gentoo-dev 2004-03-29 12:02:00 UTC
i dont really see how this is possible
Comment 2 Marius Mauch (RETIRED) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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 gentoo-dev 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) gentoo-dev 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) gentoo-dev 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