Python26 framework is not recognized by ld, causing erroneous link against system python

[Veence (Vincent)]

The following lines, part of the python26 portfile post-destroot phase:

   foreach dir { Headers Resources Python Versions/Current } {
      file delete ${destroot}${framewpath}/${dir}
   }

erase the respective links. This is maybe thought to be necessary if there is more than one version installed. But without these links, ld does not recognize the structure as a framework, and therefore will not link against it anymore, defaulting to System python framework, even with explicit -Fpath. This certainly causes #21444 and maybe others. The fix is simply to remove the lines cited.

[blb@…]

(Only one owner possible)

[blb@…]

Note that boost +python26 linked here fine, no python_select or anything:

$ otool -L /mp/lib/libboost_python-mt.dylib 
/mp/lib/libboost_python-mt.dylib:
	/mp/lib/libboost_python-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/mp/Library/Frameworks/Python.framework/Versions/2.6/Python (compatibility version 2.6.0, current version 2.6.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 124.1.1)

Note also that not removing those links means that 2.6 magically becomes the default python framework and would most likely break things like python_select, or trying to install another python version.

[Veence (Vincent)]

The problem is the way the configure script detects frameworks. On the port I'm finishing, qgis, Macports framework will not be detected if it does not link, and the path can not be forced (it uses Cmake).

Besides, python_select can be adjusted to modify the files the links point to. This is fairly simple and automatic, resulting in a link with the proper version, much the way the system python framework does.

[blb@…]

Can you modify the CMakeLists.txt file to specifically point to the right python binary (${prefix}/bin/python2.6)? This usually works right for most things using the python26 port, as they then query python for any further information.

The problem with not deleting those files is that you end up with being able to only install one python port, since they'll all want to install them. While it'd be nice to specify just one python version to support, that's definitely not currently possible with the way things are.

[Veence (Vincent)]

I've tried that. It does not work. The link flags are specifically set to "-framework Python" and, of course, adding a "-F ${frameworks_dir} will not work either. According to the Qgis developers, this is a bug in Cmake: it always queries system frameworks. It must admit I've taken that as "Gospel truth" as we say here.

Can the trio -F... -framework Python be replaced by a direct reference to e.g. -L${some_directory}? In which case it might be fixed easily. But I'm unsure this is the case.

[blb@…]

I'm definitely far from a cmake expert, but it appears that the framework stuff is happening when Python_FRAMEWORKS is set during cmake's run; can that be set unset/set to 0 to make this work? Otherwise, perhaps setting PYTHON_INCLUDE_PATH and PYTHON_LIBRARY would work to point to the right bits? The right library flags should be simply -L${prefix}/lib and -lpython2.6 as the port sets up a symlink there for just this purpose.

[dbsgeo@…]

In reply to blb, yes -L${prefix}/lib and -lpython2.6 should work but always seems to fail and I've just seen an email why, that indicates it is a python bug that they symlink is missing:

​http://mail.python.org/pipermail/pythonmac-sig/2009-December/021977.html

and

​http://mail.python.org/pipermail/pythonmac-sig/2009-December/021978.html

[dbsgeo@…]

Cc Me!

[jmroot (Joshua Root)]

Current version of python26 appears to have the fix mentioned in the messages linked in comment:7. Anything that needs the python_select symlinks to exist is doing it wrong.