Emerging packages with an alternate gcc in /usr/local/bin can result in many emerge failures. Commonly the ebuild "configure" script will fail at various points. Often the build log will contain errors like: rm: cannot remove `conftest': Is a directory but the configure script failure is usually a different error which varies with the package. The fundamental problem seems to be associated with "emerge" setting up the ebuild with /usr/local/bin in the PATH variable. There should be a specific "user choice" option (USE flag?) with respect to whether or not anything in /usr/local is "seen" during an ebuild. Reproducible: Always Steps to Reproduce: 1. Download "private" gcc from ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.1/gcc-4.1.1.tar.bz2 Extract into source directory "gcc-4.1.1" 2. Create gcc binary directory for building profiled gcc, e.g. mkdir gcc-4.1.1-profile; cd gcc-4.1.1-profile and compile "private" gcc for profiling, e.g. sh ../gcc-4.1.1/configure > 1SETUP.lst 2>&1 \ --prefix=/usr/local \ --libdir=/usr/local/libprof \ --mandir=/usr/share/man --infodir=/usr/share/info \ --libexecdir=/usr/lib/misc/glibc \ --enable-languages=c,c++,f95 --enable-threads=posix \ --with-cpu=prescott --with-arch=prescott --enable-long-long \ --enable-__cxa_atexit --enable-cstdio=stdio \ --enable-version-specific-runtime-libs \ --disable-checking --disable-nls \ --with-system-zlib One should notice (a) prefix=/usr/local and (b) --disable-checking! Why shouldn't one be able to put a profiled gcc into /usr/local? and the "gcc" configure seems to know that putting "alternate" gcc's into /usr/local may cause problems thus the need to add "--disable-checking". One suspects this is due to a history of "alternate" gcc's causing configuration failures in a variety of other packages if installed in /usr/local. 3. Run "make install" to get "i686-pc-linux-gnu-gfortran gfortran i686-pc-linux-gnu-g++ i686-pc-linux-gnu-c++ g++ c++ i686-pc-linux-gnu-gcc-4.1.1 i686-pc-linux-gnu-gcc gcc and cpp installed in /usr/local/bin. 4. Run ebuilds which build their own "configure" file. Actual Results: Ebuilds will fail. Expected Results: Ebuilds should build properly. One should be able to install *anything* into /usr/local without impacting normal Gentoo system ebuilds. If I want to install into /usr/local a compiler for my yet-to-be-purchased Playstation 3 so I can run folding@home on the Playstation Linux system it should *NOT* negatively impact Gentoo distributed system ebuilds. Having /usr/local/bin or /usr/local/lib override the default gentoo installation (say I want to compile things with gcc-4.1.2 or GNU or Xorg libraries not within the Gentoo ebuild system) should be an explicitly configurable option. But the default should be to never use /usr/local because of potential problems it causes with system ebuilds. For example, in a recent "emerge world" type update with an "alternate" gcc in /usr/local/bin, the following ebuilds failed: mysql, id3lib, dbus-glib, imagemagick, fluxbox, cairo, wireshark, evolution-data-server This is a painful bug to resolve because if one changes to the ebuild working directory and attempts to run the configure & makes by hand (as root) it works fine! So the files and ebuild work properly. What is at fault is the ebuild environment, specifically the PATH variable, when running an "emerge" vs. running what the emerge would do as root by hand. Packages that appear to be particularly effected are those which build their own "configure" at build time (this may use autoconf -- I'm not sure). This isn't a problem with /etc/env.d/00basic and /etc/ld.so.conf. I commented out LDPATH=/usr/local/lib in 00basic and rebuilt ld.so.conf and ld.so.cache with no effect. The ebuilds still failed. (However -- it is highly questionable whether 00basic should be including /usr/local/lib in the LDPATH!) The ebuild problem did resolve itself when I renamed *all* gcc files in /usr/local/bin, esp. /usr/local/bin/gcc and /usr/local/bin/i686-pc-linux-gcc and /usr/local/bin/i686-pc-linux-gnu-gcc-4.1.1. The c++ and g++ installed files probably have to be renamed as well if the package "configure" script relies on them. It is not clear to me what file controls the setting of the PATH variable for ebuilds and package autoconfigurations. (If reviewers only point out those files in this bug report so users can override them it would be a big help.) It should be noted that there may be various bug reports related to this as this problem can sometimes show up as "libtool" problems (esp. when /usr/local/lib gets dragged into the build equation).
Dupe of Bug 175129; and stuff in /usr/local really isn't our problem.
Either dupe bug 175129, or portage should exclude /usr/local in it's functional path. Not my call (both approachs can be correct in certain circumstances).
Stuff involving /usr/local *is* a Gentoo problem if putting stuff there breaks portage/ebuilds. An example of a non-Gentoo problem is if I happen to do something like "mv /bin/true /usr/bin/gcc" and that breaks the build process. I've reviewed bug 175129 and would note that the problem does *NOT* appear to be in either /etc/profile.env or /etc/profile. Those have been adjusted so that /usr/local/sbin and /usr/local/bin are not normally included in PATH. Portage/emerge seems to assemble its path through an alternate route. Question 1: In what source file is the emerge PATH variable set? I agree with Robin, that one can argue that portage should or should not include /usr/local in environment settings depending upon what one is trying to do. Therefore it should be something under user control and documented as such.
Created attachment 117035 [details, diff] Remove /usr/local/* from ebuild env SHould there be a way for users to munge with the ebuild PATH env? Bashrc would work too here; so the patch isn't necessarily required. Also I see PREROOTPATH in there; but it's not documented
The portage devs hath spoken, and I think the word is 'use /etc/portage/bashrc to change PATH to whatever you want'.
sounds good ... if user wants to put crap in their /usr/local and then have the portage env ignore it, it's up to them to do so ... putting this policy into portage is wrong
