libplist: installs a python module but doesn't depend on python

[wanthalf@…]

:info:build Linking CXX shared module _plist.so
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libplist/work/libplist-1.3/swig && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/_plist.dir/link.txt --verbose=1
:info:build /usr/bin/g++-4.2  -O2 -arch x86_64  -O3 -DNDEBUG -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -bundle -headerpad_max_install_names -L/opt/local/lib -arch x86_64 -o _plist.so CMakeFiles/_plist.dir/plistPYTHON_wrap.cxx.o ../src/libplist.1.1.3.dylib ../src/libplist++.1.1.3.dylib /opt/local/lib/libpython2.6.dylib ../src/libplist.1.1.3.dylib /opt/local/lib/libxml2.dylib /opt/local/lib/libglib-2.0.dylib 
:info:build Undefined symbols:
:info:build   "_PyCapsule_Import", referenced from:
:info:build       __wrap_Date_get_value in plistPYTHON_wrap.cxx.o
:info:build       __wrap_Date_set_value in plistPYTHON_wrap.cxx.o
:info:build       __wrap_new_Date in plistPYTHON_wrap.cxx.o
:info:build       __wrap_new_Date in plistPYTHON_wrap.cxx.o
:info:build ld: symbol(s) not found
:info:build collect2: ld returned 1 exit status
:info:build make[2]: *** [swig/_plist.so] Error 1
:info:build make[1]: *** [swig/CMakeFiles/_plist.dir/all] Error 2
:info:build make: *** [all] Error 2

[jmr@…]

Please remember to fill in the Port field and cc the maintainer.

[ryandesign@…]

Cc Me!

[wanthalf@…]

Problem found: an independent local installation of Python 2.7

Solution is to (re)move (temporarily or completely) the directory /Library/Frameworks/Python.framework/Versions/2.7/

[wanthalf@…]

Well, I think ports should take care of such possible conflicts - or at least warn the user - but you decide...

[jmr@…]

Picking up stuff in /Library instead of the equivalent in ${prefix} is not OK.

[ryandesign@…]

IMHO it's like having things installed in /usr/local. Tons of ports will pick up libraries the user has in /Library/Frameworks.

[wanthalf@…]

Yes. It is a general problem. See e.g. bug #25507

I guess the UnixImageIO.framework (which is responsible for most problems) is distributed as support package for the non-macports ("native") distribution of GRASS GIS. The Python-2.7 was probably installed of the same reason, though it is probably not necessary, as the other implementations (apple / macports) are probably sufficient for Grass...? (not sure now) Is there really no easy way to generally protect MacPorts from packages installed outside its scope? It seems the problem are only the header files - right?

[jmr@…]

The problem here is actually that libplist is installing a python module into whatever python framework it finds, and doesn't depend on any pythonXY port. We don't want a port to install anything into the system python location.

So a dependency needs to be added on a specific python port (changed in variants if desired), and cmake needs to be told to use that python.

[ryandesign@…]

Replying to jmr@…:

The problem here is actually that libplist is installing a python module into whatever python framework it finds, and doesn't depend on any pythonXY port. We don't want a port to install anything into the system python location.

So a dependency needs to be added on a specific python port (changed in variants if desired), and cmake needs to be told to use that python.

Has duplicate #30394.

This issue has had several consequences (duplicates):

• #29452 (libplist build failure on Tiger presumably because Tiger's Python is too old)
• #32500 (libplist configure fails when Python 3 has been selected)
• #33368 (libplist mtree violation when system Python is selected)

[rmstonecipher@…]

If this port depends upon swig-python, which in turn depends on python_select, how can I poll python_select to choose a python by default?
Should that be handled with variants, including a default +python27 variant?

[jmr@…]

r94991