Ned Deily added the comment:
Sorry, I've finally gotten around to taking a longer look at this and it seems
that freeze support is kind of a mess. First, it looks like some of the issues
you ran into were fixed in 3.4.1 (changes associated with Issue11824 and
Issue16047). Unfortunately, one of them introduced a new problem that I've
documented in Issue23405 (and which can be worked around by editing the freeze
Makefile to use $(LIBRARY) instead of $(LDLIBRARY)). But there appear to be
still more basic problems when trying to use freeze with OS X framework builds
such as provided by the python.org installers for OS X.
1. freeze makes use of the LINKFORSHARED configuration variable when building
the frozen executable. For OS X non-framework Python builds, it typically
looks like this:
LINKFORSHARED="-Wl,-stack_size,1000000 -framework CoreFoundation"
For framework builds, it also includes the relative framework file path:
LINKFORSHARED="-Wl,-stack_size,1000000 -framework CoreFoundation
Python.framework/Versions/3.4/Python"
The path is not useful as-is outside of the Python build itself and, by having
a path here, the OS X framework configuration seems to be an exception to most
other platforms, causing problems here with freeze and elsewhere (there have
been other complaints about this usage). As noted, one can workaround this
problem by editing the freeze-produced Makefile. But that leads to another
problem.
2. Unlike for non-shared and shared Python builds, OS X Python framework builds
do not include the Python library as a static archive file in the config-*
directory (or anywhere else for that matter). Instead, symbolic links are
created in the directory to the framework shared library.
shared build
$ ls -l ./lib/python3.4/config-3.4dm/lib*
-rw-r-----+ 1 nad pyd 9514552 Feb 7 16:57 libpython3.4dm.a
framework build
$ ls -l ./lib/python3.4/config-3.4dm/lib*
lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4.a -> ../../../Python
lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4.dylib -> ../../../Python
lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4dm.a -> ../../../Python
lrwxr-x--- 1 nad pyd 21 Feb 7 17:41 libpython3.4dm.dylib ->
../../../Python
This difference causes problems when linking the frozen executable: because the
framework build configuration presents a dynamic shared lib, the resulting
executable has a runtime dependency on the shared lib:
% otool -L hello
hello:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1152.0.0)
/Library/Frameworks/Python.framework/Versions/3.4/Python (compatibility
version 3.4.0, current version 3.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
and the frozen executable cannot be run on another system which does not have a
compatible version of Python installed. I don't know of an easy freeze build
workaround for this. I think the correct solution for freeze is to always only
provide the static library in the config* directory for all Python build
configurations. But I'm not sure whether there are any compelling reasons to
provide shared lib links as well for other users of the config* directory (e.g.
for embedding Python); if so, the static and dynamic libs may have to have
distinct names.
Ronald, do you have other thoughts on this?
At the moment, I think the safest solution for using freeze on OS X is to use a
non-shared, non-framework build of Python, which probably means building Python
3.4 yourself.
----------
nosy: +ronaldoussoren
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21502>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
