[issue11217] python-32 not linked in /usr/local/bin in framework builds

[Tom Loredo]

Tom Loredo  added the comment:

Thanks for handling this, Ned!  -Tom

--

___
Python tracker 
<http://bugs.python.org/issue11217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6

[Tom Loredo]

Tom Loredo  added the comment:

Ned-

Thanks a lot for the clarifications.  Both the tracker and modified
web page have cleared things up for me.

> "* No recommended or alternate Tcl/Tk is indicated for 32/64 on 10.6.  But 
> the 2.7.2 patched README indicates
> ActiveTcl-8.5.9 will work.  Will it not work with 2.7.1?"
> 
> No, because at the time the 2.7.1 64-bit installer was built, the Active 
> State 8.5.9 Cocoa Tk had not been released
> so that installer was built without a 3rd-party Tcl/Tk present in 
> /Library/Frameworks

I should have been clearer with my question.  I am interested in compatibility
when I build from source, which is why I was consulting the README files.  I
presume Python 2.7.1 will be happy with ActiveTcl-8.5.9 if it's present when
I build from source.  I built 2.7.1 with the TclTkAqua 8.5.9 backport, and
it works for the most part, i.e., IDLE and matplotlib start up fine and appear
to work, for a while.  I don't use IDLE much presently, but I use matplotlib a
lot with the Tk backend, and though it was stable for me with Py 2.6 and
and older Tcl/Tk, the 2.7.1/8.5.9 combo always eventually crashes for me 
(segfault)
after I've opened and closed a dozen windows or so.  I'll give ActiveTcl a try 
to
see if theirs is more stable.

That's just a "data point" for you; no need to respond.

Thanks for all your work on MacPython.

-Tom

-
This mail sent through IMP: http://horde.org/imp/

--

___
Python tracker 
<http://bugs.python.org/issue10907>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11217] python-32 not linked in /usr/local/bin in framework builds

[Tom Loredo]

New submission from Tom Loredo :

When building a universal framework Python-2.7.1 with homebrew on 10.6.6, 
python-32 (and its target, python2.7-32) are built and installed in the 
framework executable path, but they are not linked in /usr/local/bin.  
msg101156 in Issue 8089 recognized this as a general MacPython problem in a 
2.6.5 release candidate but deferred a fix for 2.6.6.  Apparently the fix was 
never implemented, or perhaps it was decided the link was not appropriate.  It 
seems to me it *is* appropriate (framework users don't currently have easy 
command-line access to python-32), but I defer to the experts!

--
assignee: ronaldoussoren
components: Macintosh
messages: 128578
nosy: ronaldoussoren, tloredo
priority: normal
severity: normal
status: open
title: python-32 not linked in /usr/local/bin in framework builds
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue11217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11217] python-32 not linked in /usr/local/bin in framework builds

[Tom Loredo]

Tom Loredo  added the comment:

I believe the main Makefile makes the Mac/Makefile.in installunixtools target 
automatically, and I don't see that it should do "the right thing" regarding 
linking a python-32.

I did the brew install again, logging the output, and adding an explicit "make 
frameworkinstallunixtools" (which I believe executes the Make makefile 
installunixtools target).  This is the log output showing that target is 
executed already by default, and that it is not linking python2.7-32:


cd Mac && make installunixtools DESTDIR=""
if [ ! -d "/usr/local/Cellar/python/2.7.1/bin" ]; then  \
/usr/local/bin/ginstall -c -d -m 755 
"/usr/local/Cellar/python/2.7.1/bin" ;\
fi
for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
  python2.7 pythonw2.7 idle2.7 \
  pydoc2.7 python2.7-config smtpd2.7.py \
  2to3-2.7 ;\
do \
ln -fs 
"/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/${fn}"
 "/usr/local/Cellar/python/2.7.1/bin/${fn}" ;\
done
==> make frameworkinstallunixtools
make frameworkinstallunixtools 
cd Mac && make installunixtools DESTDIR=""
if [ ! -d "/usr/local/Cellar/python/2.7.1/bin" ]; then  \
/usr/local/bin/ginstall -c -d -m 755 
"/usr/local/Cellar/python/2.7.1/bin" ;\
fi
for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
  python2.7 pythonw2.7 idle2.7 \
  pydoc2.7 python2.7-config smtpd2.7.py \
  2to3-2.7 ;\
do \
ln -fs 
"/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/${fn}"
 "/usr/local/Cellar/python/2.7.1/bin/${fn}" ;\
done

I don't see how the -32 versions would be linked by this part of the Makefile:


for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
  python$(VERSION) pythonw$(VERSION) idle$(VERSION) \
  pydoc$(VERSION) python$(VERSION)-config smtpd$(VERSION).py \
  2to3-$(VERSION) ;\


Looking further at the logged output, the -32 versions appear to be extracted 
from a universal pythonw:


lipo -extract i386 -output 
/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32
 pythonw
lipo -extract i386 -output 
/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7-32
 pythonw
ln -sf python2.7-32 
"/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/python-32"
ln -sf pythonw2.7-32 
"/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/pythonw-32"

I don't see how the unixtools targets will find these.

--

___
Python tracker 
<http://bugs.python.org/issue11217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6

[Tom Loredo]

Tom Loredo  added the comment:

I see this is marked as fixed but pending; perhaps the following comment will 
be useful.

I encountered the IDLE/Tk instability issue when working on the Homebrew 
formula for Python-2.6.5 a year ago (March 2010).  Building a universal 
framework Python on Intel (32/64-bit) produced an IDLE that froze when one 
created a new window, a common problem even back then.  Attempting to resolve 
the issue was further complicated by 2.6.5 not having a way to access 32-bit 
Python in a universal build (since fixed!).

I came up with three workarounds that produced Python builds for 10.6 with an 
IDLE that at least did not have the new-window freeze.  I'm not a heavy IDLE 
user, so I didn't test beyond that, and perhaps one or more of the workarounds 
would still have problems.  Two workarounds could produce 64-bit Python with a 
non-freezing IDLE; the last one could only produce a 32-bit version, but built 
on 10.6.

The workarounds:

* As already noted, installing the current ActiveTcl before building Python 
produced a working IDLE, 32-bit or 64-bit.

* I was able to build a 32/64 universal Cocoa version of Tcl/Tk 8.5 using an 
8.6beta backport; I believe I learned of it in the Tcl thread here:

http://mail.python.org/pipermail/pythonmac-sig/2010-March/thread.html

The version I used is on GitHub:

https://github.com/das/tcltk/tree/de-carbon-8-5

I have a brew formula that builds it (at least the version of March 2010) and 
installs it as a public framework, so Python can find it.  The resulting IDLE 
did not have the new windows freeze.  If this is a real fix, it might be 
helpful for users who have license issues with ActiveTcl.

* The last workaround uses the fact that Apple ships both 8.4 and 8.5 versions 
of Tcl/Tk with 10.6, though the 8.4 Tk is only 32-bit.  I hacked Python's 
setup.py to detect if a 32-bit 10.6 build is in progress; if so, it linked 
against 8.4 instead of 8.5, and it produced an IDLE that at least didn't have 
the new window freeze.  Perhaps 8.4 is old enough to have other issues, but if 
it would be acceptable as a stopgap, I'm sure Ned et al. could come up with a 
better setup.py hack than I did.  The advantage of this approach is that it 
does not require any software that doesn't ship with Snow Leopard.  Since it 
only works for 32-bit builds, it probably doesn't have advantages over 
installing the 32-bit 10.3-10.6 Python.  But if you must *build* on 10.6 and 
have a working IDLE without using ActiveTcl, this might be an option.

I find two things somewhat confusing regarding the current version of the web 
site:

* My impression was that Python's tkinter figures out what Tcl/Tk to link to at 
build time, not runtime.  The table on the web site suggests I can use a 
pre-built Python with an ActiveTcl that I install myself later.  Is this 
correct?  If so, does ActiveTcl have to be present when the installer is run, 
or can it be installed later?

* No recommended or alternate Tcl/Tk is indicated for 32/64 on 10.6.  But the 
2.7.2 patched README indicates ActiveTcl-8.5.9 will work.  Will it not work 
with 2.7.1?

Thanks a lot for your continued work on this thorny issue!

--
nosy: +tloredo
status: pending -> open

___
Python tracker 
<http://bugs.python.org/issue10907>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11217] python-32 not linked in /usr/local/bin in framework builds

[Tom Loredo]

Tom Loredo  added the comment:

I believe this is a bug.

The -32 part of Mac/Makefile.in builds and links the -32 versions here:


ifneq ($(LIPO_32BIT_FLAGS),)
lipo $(LIPO_32BIT_FLAGS) -output 
$(DESTDIR)$(prefix)/bin/python$(VERSION)-32 pythonw
lipo $(LIPO_32BIT_FLAGS) -output 
$(DESTDIR)$(prefix)/bin/pythonw$(VERSION)-32 pythonw
ln -sf python$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/python-32"
ln -sf pythonw$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/pythonw-32"
endif

For a framework build, the destinations are the framework location, and indeed 
the brew install does put them there.

Right after in Makefile.in is the unix tools part (which is run by default):

installunixtools:
if [ ! -d "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ]; then  \
$(INSTALL) -d -m $(DIRMODE) 
"$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ;\
fi
for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
  python$(VERSION) pythonw$(VERSION) idle$(VERSION) \
  pydoc$(VERSION) python$(VERSION)-config smtpd$(VERSION).py \
  2to3-$(VERSION) ;\
do \
ln -fs "$(prefix)/bin/$${fn}" 
"$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/$${fn}" ;\
done

I believe this needs an "ifneq ($(LIPO_32BIT_FLAGS),)" block that explicitly 
handles $(VERSION)-32, just like the pythonw section before it.

--

___
Python tracker 
<http://bugs.python.org/issue11217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11217] python-32 not linked in /usr/local/bin in framework builds

[Tom Loredo]

Tom Loredo  added the comment:

The attached patch does the trick.

--
Added file: http://bugs.python.org/file20792/Python-2.7.1-patch.txt

___
Python tracker 
<http://bugs.python.org/issue11217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7998] MacPython 2.7a3 posix_spawn error for build using --with-framework-name

[Tom Loredo]

New submission from Tom Loredo :

Build Py-2.7a3 on Snow Leopard OS 10.6.2 with a non-default framework name:

./configure --prefix=/usr/local/tmp --enable-framework 
--with-framework-name=PythonAlpha  --enable-universalsdk=/ 
--with-universal-archs=intel

"make" succeeds, "make test" isn't perfect but is okay:

$ make test
...
347 tests OK.
1 test failed:
test_macostools
33 tests skipped:
test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn
test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses test_dl test_epoll test_gl
test_imageop test_imgfile test_largefile test_linuxaudiodev
test_ossaudiodev test_pep277 test_py3kwarn test_smtpnet
test_socketserver test_startfile test_sunaudiodev test_timeout
test_tk test_ttk_guionly test_urllib2net test_urllibnet
test_winreg test_winsound test_zipfile64
1 skip unexpected on darwin:
test_dl
make: *** [test] Error 1

But after "make install" the installed python fails:

$ which python
/Library/Frameworks/PythonAlpha.framework/Versions/2.7/bin/python
$ python
python: posix_spawn: python: Unknown error: 0

The same failure occurs if I directly execute python, python2.7, python-32, and 
the "w" versions in the framework with a full path, or with the 
/usr/local/tmp/bin paths.

On the other hand, if I build with the same config but omitting the framework 
name change:

./configure --prefix=/usr/local/tmp --enable-framework --enable-universalsdk=/ 
--with-universal-archs=intel

the command line interpreter is now fine:

$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python
$ python
Python 2.7a3 (r27a3:78020, Feb 23 2010, 02:07:19) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
...

By the way, in either case, python-32 (and its variants) are in the
framework but are *not* linked under the prefix (e.g., here they are
not in /usr/local/tmp/bin).  I don't know if this is intentional or not; it 
seems undesirable to me.

--
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 99902
nosy: ronaldoussoren, tloredo
severity: normal
status: open
title: MacPython 2.7a3 posix_spawn error for build using --with-framework-name
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue7998>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7998] MacPython 2.7a3 posix_spawn error for build using --with-framework-name

[Tom Loredo]

Tom Loredo  added the comment:

> Ronald Oussoren  added the comment:
> 
> Fix in r78755 (2.7) and r78756 (3.2)

Thanks for your attention to this, Ronald---and all the hard
work on the OS X support.

-Tom

-
This mail sent through IMP: http://horde.org/imp/

--

___
Python tracker 
<http://bugs.python.org/issue7998>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6

[Tom Loredo]

Tom Loredo  added the comment:

Attempted to build 2.6.5rc2 on Mac Pro (2006), OS 10.6.2, following 
instructions in Mac/README:

./configure --prefix=/usr/local/tmp --enable-framework 
--with-universal-archs=intel --enable-universalsdk=/

Results of "make test" are as expected from past experience (but what 
architecture is being tested?):

332 tests OK.
2 tests failed:
test_asynchat test_smtplib
32 tests skipped:
test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn
test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses test_dl test_epoll test_gl
test_imageop test_imgfile test_largefile test_linuxaudiodev
test_normalization test_ossaudiodev test_pep277 test_py3kwarn
test_smtpnet test_socketserver test_startfile test_sunaudiodev
test_timeout test_urllib2net test_urllibnet test_winreg
test_winsound test_zipfile64
1 skip unexpected on darwin:
test_dl

Notably, test_tcl passes without incident.

Running the following within the installation directory runs the 64-bit 
pre-installation executable (judging by sys.maxint):

$ DYLD_FRAMEWORK_PATH=`pwd`: python.exe

Thus I presume it is the 64-bit version being run by "make test".

The installed IDLE still has the Tk new window freeze issue; sys.maxint 
indicates it's the 32-bit version that is running when launcing IDLE.  I have a 
setup.py patch that will detect a 32-bit 10.6 installation and link against 
Apple's Tcl/Tk-8.4 compatibility version if the user hasn't
installed their own Tcl/Tk frameworks, but it's an ugly hack and I'm not sure 
this is desirable; we should probably just encourage installing newer Tcl/Tk.  
The hack does produce a working 32-bit IDLE, however.

Running "python" on the command line runs the 32-bit version; is this intended? 
 I think the default behavior for universal builds should be documented in the 
Mac/README, or at some location pointed to in the README.

I still see no way to access the two architectures.  My ./configure installs 
command line executables in /usr/local/tmp/bin, a non-existing directory before 
the install.  After installation, its contents are:

idle@ pydoc2.6@ python2.6@pythonw2.6@
idle2.6@  python@   python2.6-config@ smtpd.py@
pydoc@python-config@pythonw@  smtpd2.6.py@

I was expecting something along the lines of python-32 and/or python-64 to be 
here; what is the intended mechanism for accessing the two architectures?

$ arch -i386 python
gives me the (default) 32-bit version.

$ arch -x86_64 python
arch: posix_spawnp: python: Bad CPU type in executable

Whereas before with a universal install like this I was getting a 64-bit 
default and no way to access 32-bit (IIRC), now I appear to be in the reverse 
scenario.

Is there an error in my build process, or is there still an installation bug 
for dual-architecture Intel installs?

--
nosy: +tloredo
type:  -> behavior
versions: +Python 2.6 -Python 3.1

___
Python tracker 
<http://bugs.python.org/issue8089>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6

[Tom Loredo]

Tom Loredo  added the comment:

Ned-

I *did* run "make install"; everything I reported was about the situation 
*after* running "make install".  In particular, I don't know any way to get 
access to IDLE without "make install"; what I described came from using the 
version in Applications/Python 2.6, which only appears after "make install".

Okay, now I see my misunderstanding---the arch-dependent executables are in the 
framework only, and not linked in the installation prefix.  Is that the 
intended behavior?  I do put my framework in my PATH so I do have access to the 
executables; but I was expecting them to be in /usr/local/... as well.

The version pointed to in /usr/local/... is the 32-bit version.  This should be 
documented somewhere; I believe it changes previous behavior.  It's not obvious 
to me what to expect here, which again argues that it should be documented.

--

___
Python tracker 
<http://bugs.python.org/issue8089>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6

[Tom Loredo]

Tom Loredo  added the comment:

> the python-32 executable has never been linked into /usr/local/bin.

What I meant by "the version pointed to" is:  The "python" command
in 2.6.4 produced by an "intel" universal build (whether in the
framework or the install prefix) executed as 64-bit.  I
don't believe it linked to either python-32 or -64; I don't think those
were even installed in 2.6.4.  I think it was a bundle that just
happened to execute as 64-bit (and provided no access to 32-bit
python).  So the "python" command-line behavior under 2.6.5rc2 is
different from what it was for 2.6.4.  I don't think this is a 
significant regression, as the previous behavior was never documented 
and was actually somewhat problematic.  I'm just pointing it out for 
documentation purposes.

> I always add the framework to $PATH because distutils installs scripts into 
> that location.

Yes, I do the same.  Still, I think your proposed plans for linking in the 
prefix in 2.7/3.2 make a lot of sense.

--
versions: +Python 2.6 -Python 3.1

___
Python tracker 
<http://bugs.python.org/issue8089>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8089] 2.6/3.1 32-bit/64-bit universal builds always run in 64-bit on 10.6

[Tom Loredo]

Tom Loredo  added the comment:

> Unless you vehemently disagree, I am not making this a release blocker for 
> 2.6.5.

I'm not sure who you are asking (I doubt it was me!), but I don't consider this 
a release blocker.  The only possible substantive issue is whether "python" 
should run 32-bit or 64-bit Python after a universal framework install.  
Previously it ran 64-bit, but that was probably accidental.  I don't have a 
strong opinion about this; others should weigh in appropriately.

I think a change in behavior here would only negatively impact a very small 
number of users (those who built from source on OS X, and who built universal 
versions on a 64-bit platform, and who count on 64-bit default behavior).  For 
example, they may have built 64-bit extensions that could appear broken after 
an update to 2.6.5 if they don't know they should use "python-64".

In my opinion the main part of the "source" at issue here is not really source 
but the Mac/README file; but this is certainly not the only subtlety of 
Python-on-OS X that is not yet covered there!

--

___
Python tracker 
<http://bugs.python.org/issue8089>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com