Precompiled binary packages incompatible with installed dependencies

[macports.org@…]

Trying to launch a GTK2 application, I was getting the following error on startup:

Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 30, in <module>
    import gobject as _gobject
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/gobject/__init__.py", line 26, in <module>
    from glib import spawn_async, idle_add, timeout_add, timeout_add_seconds, \
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/glib/__init__.py", line 22, in <module>
    from glib._glib import *
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/glib/_glib.so, 2): Symbol not found: _PyUnicodeUCS2_DecodeUTF8
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/glib/_glib.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/gtk-2.0/glib/_glib.so

I tried reinstalling gobject several times as the file in question is provided by that port and it *still* wouldn't work. Engaging my brain and actually looking at the logs, I finally realized that macports was downloading the binary packages instead of the source…

And it turns out that binary package apparently uses the default compilation options, my local Python 2.6 is installed with +ucs4, and those are of course binary incompatible but Macports's binary build system seems unable to understand the distinction, leading to installing a broken binary package.

[neverpanic (Clemens Lang)]

This problem is probably not limited to py26-gobject, but to every python module using native code. Either all python modules should have the ucs4 variants, or the python26 port should drop the variant and just provide what works for most users (like binary distributions, e.g. debian, do).

[macports.org@…]

This problem is probably not limited to py26-gobject, but to every python module using native code.

Aye, and maybe other interpreters as well when they have a switch with such an influence on binary compatibility. Technically, any port with variants on which other ports depend can have such an issue if it's installed from source and its dependencies are installed from binary.

Either all python modules should have the ucs4 variants, or the python26 port should drop the variant

Or the binary distribution system could have some additional smarts like variant dependencies/undependencies (e.g. binaries without +ucs4 would not be installed on a machine with +ucs4). But I don't know anything about variants handling or the new binary system, so I don't know if that's possible.

A simple way to "fix" the issue would be to use binary packages when all dependencies were installed from binaries, but that's going to be far less interesting for existing installations as they're mostly installed from source.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Python 2.6 is ​no longer being maintained upstream, python26 currently has no maintainer (r127635), and this ticket has had no activity for some time.
It seems unlikely that this will be fixed.