classification
Title: Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Type: compile error Stage:
Components: Build, macOS Versions: Python 3.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: ned.deily, ronaldoussoren, srid, tarek
Priority: normal Keywords:

Created on 2009-06-02 00:00 by srid, last changed 2009-06-26 23:42 by srid. This issue is now closed.

Messages (19)
msg88689 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-02 00:00
$ make frameworkinstall DESTDIR=[...]/py3_1rc1-macosx-apy31-rrun/image
running install_scripts
[...]
copying build/scripts-3.1/2to3 ->
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
error:
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
Too many levels of symbolic links
make: *** [sharedinstall] Error 1


!
!

this appears to be a regression in 3.1rc1 (used to work with 3.1b2).
need to investigate further. will update this bug if I find anything
useful. (quick observation .. 'install_scripts' seem to be run twice)
msg88690 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-02 00:01
To explain further, the following section of script is run *twice* .. 
and thus explains the error "Too many levels of symbolic links"

mv 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3" 
"[...]]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1"
ln -sf 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3-3.1" 
"[...]/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3"

The entire log file is here: http://double.activestate.com/t/apy31-anole.log

On 09-06-01 04:46 PM, Sridhar Ratnakumar wrote:
> >
> > make: [image_python] PythonLauncher build attempt 1 of 2 (see bug 44709)
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstallapps
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> > make: [image_python] running 'cd build/py3_1rc1-macosx-apy31-rrun/python
> > &&  make frameworkinstall frameworkinstallextras
> >
DESTDIR=/Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image'
> > [...]
> >
> >
> > Note: the second make attempt uses 'frameworkinstallextras' as the extra
> > argument.
> >
> > .
> > .
> >
> > This appears to be breaking 3.1rc1 on Mac ("Too many levels of symbolic
> > links"):
> >
> > running install_scripts
> > [...]
> > copying build/scripts-3.1/2to3 ->
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin
> > error:
> >
//Users/apy/rrun/build/activepython-svn-trunk/build/py3_1rc1-macosx-apy31-rrun/image/Library/Frameworks/Python.framework/Versions/3.1/bin/2to3:
> > Too many levels of symbolic links
> > make: *** [sharedinstall] Error 1
msg88691 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-02 00:02
Tarek, are you perchance aware of any change that went into distutils
since the last beta release that could have influenced the make behavior?
msg88693 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-06-02 00:10
No, but I am running frameworkinstall right now under Mac to see if I
can reproduce the problem
msg88694 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-02 00:12
To help with the repro, may I suggest running the following in the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image
msg88696 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-06-02 00:24
I'll try tomorrow asap (sorry it's 2:30 am now here)
msg88697 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-02 00:27
also related to issue 5756
msg88721 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-06-02 07:18
The URL you provide for the log doesn't seem to be accessible externally 
so it is difficult to guess exactly what was being done.  However, there 
were changes between 3.1b2 and 3.1rc1 to the top-level Makefile 
(Makefile.pre.in) and to the Mac/Makefile.in affecting framework builds 
and installs.
msg88726 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-06-02 09:01
Sorry I can't reproduce it,

can you tell me how you run configure precisely ?
eg the whole set of commands after a fresh checkout
msg88728 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-02 09:07
I also cannot reproduce this, using both the py3k branch and the r31rc1 
tag. 

My build procedure:

* cd r31rc1
* mkdir build
* cd build
* ../configure --enable-framework --enable-universalsdk
* make
* make install DESTDIR=$PWD/image

The resulting framework in the $DESTDIR seems to be complete, and I 
don't get errors while building it.
msg88731 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-02 09:17
Now I'm really confused, I tried  to install a second time and this time I 
do get an error. 

Time to start hunting down an issue...
msg88732 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2009-06-02 09:19
Ronald, did you try Sridar precise sequence after Pyhon was built ?

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image
msg88733 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-02 09:21
Manually running "make frameworkinstallframework" (and the other ones) is 
not supported, those are internal makefile targets that are are used to 
implement "make install". 

"make framworkinstall" is supported as an alias for "make install" because 
the former was the only way to install a framework for a long time.
msg88736 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-02 10:12
I found the issue.

In r72899 antoine.pitrou checked in a change that adds these two lines 
to the bininstall target in Makefile.pre.in:

   -rm -f $(DESTDIR)$(LIBPC)/python3.pc
   (cd $(DESTDIR)$(LIBPC); $(LN) -s python-$(VERSION).pc python3.pc)

This exposes a bug in the configure script, which causes target 
'bininstall' to run before 'libainstall' when your doing a framework 
install.  The latter target is the one that creates python-
$(VERSION).pc, which is why we get build failures.

What I don't understand is why I've been able to install frameworks all 
along and didn't notice this before. 

I'm working on a patch, and will check that in after I've full tested 
it.

The important bit of the patch is this change to configure.in:

-		FRAMEWORKALTINSTALLFIRST="frameworkinstallstructure 
bininstall maninstall"
+		FRAMEWORKALTINSTALLFIRST="frameworkinstallstructure "
msg88737 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-02 10:56
This should be fixed in r73142, please test.
msg88784 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2009-06-03 01:57
That seems to work.  However, while testing that, I found another, minor 
problem in that same area.  In Makefile.pre.in bininstall target just 
before the lines you cite, there is also this added in r71935:

-rm -f $(DESTDIR)$(BINDIR)/python3-config
(cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)-config python3-
config)

Prior to that, though, the Mac Makefile target install_versionedtools is 
mucking in the same area:

if [ ! -h "$(DESTDIR)$(prefix)/bin/python3-config" ]; then \
  mv "$(DESTDIR)$(prefix)/bin/python3-config" 
"$(DESTDIR)$(prefix)/bin/python$(VERSION)-config" ;\
  ln -sf "python$(VERSION)-config" "$(DESTDIR)$(prefix)/bin/python3-
config" ; \
fi

and, in fact, the mv fails with an error because (1) the python3-config 
hasn't been created yet and (2) the test is incorrect: ! -h is also true 
if the file doesn't exist.  With the code in bininstall, I think these 
lines can be safely removed from install_versionedtools.
msg88852 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-03 23:38
Ronald, a quick note - your fix unfortunately did not solve the issue.

[quote]'To help with the repro, may I suggest running the following in
the same
order:

   make frameworkinstallframework DESTDIR=image
   make frameworkinstallapps DESTDIR=image
   make frameworkinstall frameworkinstallextras DESTDIR=image
'[endquote[
msg88853 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2009-06-03 23:41
Don't do that, use 'make install DESTDIR=$PWD/image'. As I mentioned 
earlier 'make frameworkinstallframework' is an internal step that 
shouldn't be used on its own.
msg89747 - (view) Author: Sridhar Ratnakumar (srid) Date: 2009-06-26 23:42
Ok, I am no longer relying on internal targets .. and this problem is 
fixed for me. It needs to be closed, correct?
History
Date User Action Args
2009-06-26 23:42:36sridsetstatus: open -> closed

messages: + msg89747
2009-06-04 06:32:14tareksetassignee: tarek ->
2009-06-03 23:41:23ronaldoussorensetmessages: + msg88853
2009-06-03 23:38:05sridsetmessages: + msg88852
2009-06-03 01:57:58ned.deilysetstatus: pending -> open

messages: + msg88784
2009-06-02 10:56:39ronaldoussorensetstatus: open -> pending
resolution: fixed
messages: + msg88737
2009-06-02 10:12:49ronaldoussorensetnosy: ronaldoussoren, tarek, ned.deily, srid
messages: + msg88736
components: + macOS, - Distutils, 2to3 (2.x to 3.x conversion tool)
2009-06-02 09:21:40ronaldoussorensetmessages: + msg88733
2009-06-02 09:19:44tareksetmessages: + msg88732
2009-06-02 09:17:49ronaldoussorensetmessages: + msg88731
2009-06-02 09:07:35ronaldoussorensetmessages: + msg88728
2009-06-02 09:01:01tareksetmessages: + msg88726
2009-06-02 07:19:18ned.deilysetnosy: + ronaldoussoren, ned.deily
messages: + msg88721
2009-06-02 00:27:33sridsetmessages: + msg88697
components: + Build, 2to3 (2.x to 3.x conversion tool)
2009-06-02 00:24:30tareksetmessages: + msg88696
2009-06-02 00:12:11sridsetmessages: + msg88694
2009-06-02 00:10:13tareksetmessages: + msg88693
2009-06-02 00:02:32sridsetmessages: + msg88691
2009-06-02 00:01:28sridsetmessages: + msg88690
2009-06-02 00:00:48sridsetfiles: - apy31-anole.log
2009-06-02 00:00:39sridcreate