You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
'./configure; make install' fails in setup.py step if .pydistutils.cfg specifies 'home' #50388
bpo-4655: during Python installation, setup.py should not use .pydistutils.cfg
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2013-02-20.08:53:50.768>created_at=<Date2009-05-28.21:01:53.709>labels= ['build']
title="'./configure; make install' fails in setup.py step if .pydistutils.cfg specifies 'home'"updated_at=<Date2013-02-20.08:53:50.766>user='https://github.com/bitdancer'
With current trunk, after a make distclean; ./configure; make install
sequence, I get the following error:
[...]
# Substitution happens here, as the completely-expanded BINDIR
# is not available in configure
sed -e "s,@exename@,/usr/local/bin/python2.7," < ./Misc/python-config.in
python-config
/usr/bin/install -c python-config /usr/local/bin/python2.7-config
rm python-config
./python -E ./setup.py install \
--prefix=/usr/local \
--install-scripts=/usr/local/bin \
--install-platlib=/usr/local/lib/python2.7/lib-dynload \
--root=/
running install
error: must supply either home or prefix/exec-prefix -- not both
make: *** [sharedinstall] Error 1
I figured it out. It turns out that a while back I created a
.pydistutils.cfg file and put home in there.
There is a bug here, of some sort. Either the .pydistutils.cfg file's
install clause should override the default --prefix somehow, or the
error message should indicate where the setting for 'home' and
'--prefix' came from to enable the user to debug the configuration. In
the latter case there would also need to be a way to explicitly tell
either make install or configure to ignore .pydistutils.cfg. In the
former case, an explicit --prefix passed to configure would need to
override .pydistutils.cfg.
Or perhaps there's some other solution I'm not seeing at the moment.
changed the title [-]./configure; make install fails in setup.py step[/-][+]'./configure; make install' fails in setup.py step if .pydistutils.cfg specifies 'home'[/+]on May 28, 2009
Activity
bitdancer commentedon May 28, 2009
With current trunk, after a make distclean; ./configure; make install
sequence, I get the following error:
[...]
# Substitution happens here, as the completely-expanded BINDIR
# is not available in configure
sed -e "s,@exename@,/usr/local/bin/python2.7," < ./Misc/python-config.in
tarekziade commentedon May 28, 2009
works for me under MacOS X, I am trying now under debian
bitdancer commentedon May 28, 2009
Benjamin can't reproduce it either. Must be something weird in my
environment, so I'm lowering the priority.
tarekziade commentedon May 28, 2009
Ok.
I confirm it works fine on a standard debian as well
bitdancer commentedon May 28, 2009
I can see that 'self.home' is '~' when that error message is generated,
but I can't figure out where self.home gets set. Any clues you can give me?
bitdancer commentedon May 28, 2009
I figured it out. It turns out that a while back I created a
.pydistutils.cfg file and put home in there.
There is a bug here, of some sort. Either the .pydistutils.cfg file's
install clause should override the default --prefix somehow, or the
error message should indicate where the setting for 'home' and
'--prefix' came from to enable the user to debug the configuration. In
the latter case there would also need to be a way to explicitly tell
either make install or configure to ignore .pydistutils.cfg. In the
former case, an explicit --prefix passed to configure would need to
override .pydistutils.cfg.
Or perhaps there's some other solution I'm not seeing at the moment.
[-]./configure; make install fails in setup.py step[/-][+]'./configure; make install' fails in setup.py step if .pydistutils.cfg specifies 'home'[/+]merwok commentedon Nov 18, 2010
See bpo-4655. (Not sure which one is the superseder.)
ned-deily commentedon Feb 20, 2013
Let's consolidate these.