Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 297364

Summary: portage-2.2_rc59 inconsistently uses an internal value of PATH and PATH from the environment during different phases
Product: Portage Development Reporter: Kevin Wilson <kwilson>
Component: CoreAssignee: Portage team <dev-portage>
Status: VERIFIED TEST-REQUEST    
Severity: major    
Priority: High    
Version: 2.2   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Kevin Wilson 2009-12-18 00:33:21 UTC
I'm using portage-2.2_rc59.

In /usr/lib/portage/bin/ebuild.sh, the function ebuild_main() re-defines PATH, rather than taking it from the environment. This is new behavior from 2.1.x.y. Here is the line that does it:: 

PATH=$ebuild_helpers_path:$PREROOTPATH${PREROOTPATH:+:}/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin${ROOTPATH:+:}$ROOTPATH

If PREROOTPATH or ROOTPATH are defined, they're {pre,ap}pended to this new PATH with requisite ':' characters. Otherwise, they're ignored.

The problem is that portage uses both this PATH and the PATH from the environment inconsistently during the same job in a way that's relatively easy to demonstrate.

I need to compile several packages with gcc-3.4.x, many of them being fortran code that for various reasons relating to my users (physicists) must be compiled with g77 rather than gfortran. I have set up some environment files in /etc/portage/env that look like the following:

/etc/portage/env/sci-libs/blas-reference::

PREROOTPATH="$(gcc-config -B i686-pc-linux-gnu-3.4.6)"
PATH="$PREROOTPATH:$PATH"
LD_LIBRARY_PATH="$(gcc-config -L i686-pc-linux-gnu-3.4.6):$LD_LIBRARY_PATH"
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
FC="g77"

If you remove the PATH definition from that file and ``emerge -1 blas-reference``, code from fortran.eclass will detect that there are two fortran compilers in the internally-modified PATH, but when the configure stage runs, only the system gcc version's fortran compiler (in my case, gfortran) will be detected.

Add the PATH definition back, and all goes as expected. 

Change the PREROOTPATH definition to be PATH=... instead of PREROOTPATH=... and only the system fortran compiler will be detected, causing the build to stop when it can't find $FC (g77) in the internally-modified PATH.

In order for portage to find g77, it needs to be *both* in the internal PATH (using {PRE,}ROOTPATH) *and* in the environment PATH.

This is broken behavior! We have a situation where portage redefines PATH for section A, and then uses a completely different PATH in section B, which happens to depend on the result of A! If these two versions of PATH are different, unexpected behavior will arise, as in this case where portage thinks g77 is both available and unavailable! It's Schroedinger's fortran compiler.

Reproducible: Always

Steps to Reproduce:
1. Put the following in /etc/portage/env/sci-libs/blas-reference::

PREROOTPATH="$(gcc-config -B i686-pc-linux-gnu-3.4.6)"
PATH="$PREROOTPATH:$PATH"
LD_LIBRARY_PATH="$(gcc-config -L i686-pc-linux-gnu-3.4.6):$LD_LIBRARY_PATH"
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
FC="g77"

2. Install both gcc-4.3.x and gcc-3.4.y.
3. Use gcc-config to set the default compiler to gcc-4.3.x.
3.5 (refresh your enviroment: source /etc/profile or logout)
4. $ emerge -1 blas-reference
5. Remove the PREROOTPATH line and repeat. Add it back, remove the PATH line and repeat. Remove both lines and repeat.
 

Actual Results:  
Both lines present: package compiles with g77 from gcc-3.4.x

Only PATH present: emerge dies when fortran.eclass' fortran_pkg_setup() cannot find g77, the compiler specified in $FC, in ebuild.sh's ebuild_main() modified PATH.

Only PREROOTPATH present: fortran_pkg_setup() detects both g77 and gfortran, but during the configure phase, gfortran is used because g77 is not present in PATH from the environment -- even though it is present in the redefined PATH.

Expected Results:  
Either PREROOTPATH should be needed to add things to the internal redefined PATH or PATH from the environment should be used for an entire emerge. Portage should use the same PATH everywhere internally so it doesn't get confused about what compilers are available. With PREROOTPATH defined, package should compile with gcc-3.4.x's g77.

Thank you for reading this very long bug report.
Comment 1 Zac Medico gentoo-dev 2009-12-24 06:31:45 UTC
I didn't pay attention to all the details here, but I've adjusted the PATH handling in portage-2.1.7.16 and 2.2_rc61. Hopefully that solves your problem. Please test.
Comment 2 Zac Medico gentoo-dev 2009-12-29 07:21:44 UTC
Please reopen if this is still a problem.
Comment 3 Kevin Wilson 2010-01-05 21:54:42 UTC
(In reply to comment #2)
> Please reopen if this is still a problem.
> 

(In reply to comment #1)
> I didn't pay attention to all the details here, but I've adjusted the PATH
> handling in portage-2.1.7.16 and 2.2_rc61. Hopefully that solves your problem.
> Please test.
> 

Thank you. I will test it soon.

Comment 4 Kevin Wilson 2010-01-05 23:34:04 UTC
(In reply to comment #1)
> I didn't pay attention to all the details here, but I've adjusted the PATH
> handling in portage-2.1.7.16 and 2.2_rc61. Hopefully that solves your problem.
> Please test.
> 

It seems to work -- I just recompiled a set of 7 sci-physics/sci-libs packages with only PREROOTPATH set in my env files, and they all did what I expect. Thanks for the fix.
Comment 5 Zac Medico gentoo-dev 2010-01-06 16:03:39 UTC
You're welcome.