[issue21502] freeze.py not working properly with OS X framework builds

[Ned Deily]

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 <report at bugs.python.org>
<http://bugs.python.org/issue21502>
_______________________________________