date:20181011

[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

2018-10-11 Thread Chih-Hsuan Yen



Chih-Hsuan Yen  added the comment:

Here is partial backtrace from commit 1d26c72e6a9c5b28b27c158f2f196217707dbb0f:

#0  0x76763197 in GetTkFontAttributes 
(faPtr=faPtr@entry=0x55cd91e8, ftFont=)
at /usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:167
#1  0x767639fa in InitFont (tkwin=tkwin@entry=0x55ee94a0, 
pattern=pattern@entry=0x55cfc690, fontPtr=0x55cd91b0, 
fontPtr@entry=0x0) at /usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:313
#2  0x76763c4e in TkpGetFontFromAttributes 
(tkFontPtr=tkFontPtr@entry=0x0, tkwin=tkwin@entry=0x55ee94a0, 
faPtr=0x55d1e8b8) at 
/usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:482
#3  0x766b5ee2 in Tk_AllocFontFromObj (interp=0x55c4b900, 
tkwin=tkwin@entry=0x55ee94a0, objPtr=0x55e39000)
at /usr/src/debug/tk8.6.8/unix/../generic/tkFont.c:1158
#4  0x766ac053 in DoObjConfig (interp=interp@entry=0x55c4b900, 
recordPtr=recordPtr@entry=0x55e53390 "0r\354UUU", 
optionPtr=optionPtr@entry=0x55f4e010, valuePtr=, 
valuePtr@entry=0x55e39000, 
tkwin=tkwin@entry=0x55ee94a0, savedOptionPtr=savedOptionPtr@entry=0x0) 
at /usr/src/debug/tk8.6.8/unix/../generic/tkConfig.c:717
#5  0x766ace92 in Tk_InitOptions (interp=interp@entry=0x55c4b900, 
recordPtr=recordPtr@entry=0x55e53390 "0r\354UUU", 
optionTable=optionTable@entry=0x55f4de10, tkwin=0x55ee94a0) at 
/usr/src/debug/tk8.6.8/unix/../generic/tkConfig.c:496
#6  0x767250b2 in CreateWidget (sharedPtr=0x55ec7230, 
tkwin=, interp=0x55c4b900, 
parent=, objc=, objv=) at 
/usr/src/debug/tk8.6.8/unix/../generic/tkText.c:664
#7  0x762efe16 in TclNRRunCallbacks () from /usr/lib/libtcl8.6.so
#8  0x767eba0c in Tkapp_Call (selfptr=0x740242b0, args=)
at /home/yen/Projects/cpython/Modules/_tkinter.c:1508

Looks more like a Tk issue than a CPython one.

For Arch Linux packagers: adding checkdepends=('ttf-font') to PKGBUILD can fix 
testing errors. Here's an example: 
https://github.com/archlinuxcn/repo/commit/e4de4598bccd44ba38c37854dc5edfb490dbe09a

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks

2018-10-11 Thread Ned Deily

Ned Deily added the comment:

macOS 10.14 appears to have introduced some subtle differences in the search
order for finding header files and/or frameworks and libraries. I'm not 100%
sure I understand completely what has changed but I'm confident that the
workaround outlined below should get you going until we have a better solution
(but beware of the potential gotcha).

Python has never fully supported building only from an Xcode-only installation,
i.e. we have required at a minimum installing system header files into
/usr/include et al by using "xcode-select --install". As of 10.14,
xcode-select no longer installs header files in /usr/include. So that further
cripples Python builds in that header files for several third-party libraries
shipped with macOS are no longer found, like zlib and sqlite3. When using an
Xcode-only installation (no Command Line Tools) in previous releases of macOS,
I believe it was the case that essentially the system root directory ('/') was
searched by the compiler tool chain for header files, for libraries, and for
frameworks, and for frameworks the long standard fallback framework search path
order was honored by default: first search /Library/Frameworks, then
/System/Library/Frameworks. That worked fine if you were installing frameworks
like Tcl and TK into /Library/Frameworks and wanting them to override the system
ones. If you did not install the Command Line Tools, then the tool chain
used the MacOSX.sdk embedded in Xcode.app as the system root for searching. By
default, that's found in:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

With an unmodified Xcode install, that directory contains usr and System
directories but no Library. So the contents of /Library were ignored by the
tool chain with the net effect that _tkinter builds would also link with the
Apple-supplied Tcl and Tk 8.5 in /System/Library/Frameworks.

With 10.14, Xcode-only installs still work the same way but now Command Line
Tools seem to effectively use the SDK embedded in
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk as the system root, rather
than the system /. Just like the Xcode copy of the sdk, the CLT copy does not
have a Library directory so now the results are the same as Xcode-only builds:
_tkinter only links with the /System/Library Tcl and Tk. From the viewpoint of
developers trying to build applications for distribution to others, it makes
sense to try to ensure that /Library does not influence the build because
/Library is under user control, not the system (Apple).

Until we "recently" started shipping our private version of Tcl and Tk 8.6.x,
which we do not install to /Library btw, it made sense to default to linking to
/Library and falling back to /System/Library, allowing optional use of a
third-party Tcl/Tk (like from ActiveState) and it all sort of worked if you
used the tool chain from the CLT. But with 10.14, that no longer works.
Python's build system complicates this all in large part because the top-level
setup.py tries to guess what directories the compiler tool chain are going to
search; that was always kind of iffy and now it's much more broken with macOS
10.14. There are ways to work around most of the issues but we need to have
better default behavior. That's kind of a bigger deal.

For the specific case of building _tkinter to link with Tcl and Tk frameworks
in /Library, I think the easiest workaround is to add a Library symlink to the
SDK in use, either under /Library/Developer/CommandTools or
/Applications/Xcode.app. "xcode-select --print-path" will show which one is in
use, but, alas, not the full path to the SDK.

either:
$ xcode-select --print-path
/Library/Developer/CommandLineTools
$ cd /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/

or:
$ xcode-select --print-path
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version -sdk macosx Path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
$ cd $(xcodebuild -version -sdk macosx Path)

You can then carefully create a symlink from the SDK to /Library.

$ sudo ln -s /Library .

Now the Python builds should find the Current version of Tcl and Tk frameworks
in /Library.

*But* be aware that this might affect other builds if there are other
frameworks you have installed in /Library. So this workaround should be used
with caution and you might consider removing the symlink once you are done
building Python.

There are other, more complicated workarounds but this seems to me to be the
simplest and most foolproof as long as one is aware of the risks and is
prepared to potentially recreate the Library symlink after software updates to
Xcode or the Command Line Tools.

--
assignee: -> ned.deily
priority: normal -> high
title: 3.7.0 _tkinter module links against /System/Library/Frameworks ->
_tkinter built on macOS 10.14 does not link t

60 matches

Mail list logo