Adam Stewart added the comment:
Thanks, that does help. Spack uses both `--with-tcltk-includes` and
`--with-tcltk-libs`, and actually RPATHs the libraries in place. According to
otool, that is all working fine:
$ otool -L
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang
Adam Stewart added the comment:
And... now it's not working again. Can you clarify exactly how tkinter finds
tk/tcl? Does it rely on TCL_LIBRARY or TK_LIBRARY env vars? TCLLIBPATH? If I
use all of these env vars, tkinter finds tcl/tk, but commands like:
$ python -m tkinter
$ python -c
Adam Stewart added the comment:
I think I FINALLY figured out the problem. We were setting `TCLLIBPATH` to
`/lib/tk8.6` when it should be `/lib`. With this change,
tkinter seems to work for me. Thanks for all of your help!
--
___
Python tracker
Adam Stewart added the comment:
Thanks, in that case it sounds like the problem is that Spack installs tcl and
tk to separate directories, but since tk depends on tcl and not the other way
around, tcl has no way of knowing where tk is installed. I'll see if I can
convince the other Spack
New submission from Adam Stewart :
I'm trying to install Python with tkinter support using the Spack package
manager. Spack adds the following flags to configure during install:
```
'--with-tcltk-libs=-L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11
Change by Adam Stewart :
--
pull_requests: +16178
pull_request: https://github.com/python/cpython/pull/16588
___
Python tracker
<https://bugs.python.org/issue26
Adam Stewart added the comment:
I also tried building with a Homebrew-installed GCC 6.2.0 but that had the same
result.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Adam Stewart added the comment:
Made a mistake. Please see the new output of DYLD_PRINT_LIBRARIES. This time I
actually ran a Python command to see which libraries were loaded.
--
Added file: http://bugs.python.org/file46745/dyld_print_libraries.txt
Adam Stewart added the comment:
The output of DYLD_PRINT_LIBRARIES is attached as well.
--
Added file: http://bugs.python.org/file46744/dyld_print_libraries.txt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Adam Stewart added the comment:
I agree, the `--enable-shared` fix is nice, but I would also love to squash
this bug.
An interesting piece of information: When I provide the full path to the
executable (not just relying on the hashed python location), I see:
$
/Users/Adam/spack/opt/spack
Adam Stewart added the comment:
> I'm certainly not going to try to deeply analyze a build that inserts *that*
> many separate -I and -L options into the compiler calls
I believe those were necessary to get the build working. Spack doesn't install
anything into /usr/, and without those
New submission from Adam Stewart:
I'm trying to build Python 2.7.13 with clang on macOS 10.12.3 with the Spack
package manager, but it fails to build the _io module. The exact error message
from the build log can be seen here:
https://github.com/LLNL/spack/issues/3478#issuecomment-287548431
Adam Stewart added the comment:
Works for me, thanks Wolfgang!
--
resolution: -> not a bug
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Adam Stewart:
I'm writing a wrapper that optionally accepts a file and reads more options
from that file. The wrapper then needs to pass all of these options and the
file to another program (qsub). Here is a minimal example to reproduce the
behavior I'm seeing:
>>&g
14 matches
Mail list logo
