Opened 13 years ago

Closed 12 years ago

#27094 closed defect (fixed)

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

Reported by: wanthalf@… Owned by: rmstonecipher@…
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port: libplist

Description

: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

Change History (13)

comment:1 Changed 13 years ago by jmroot (Joshua Root)

Owner: changed from macports-tickets@… to rmstonecipher@…
Port: libplist added

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

comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Cc Me!

comment:3 Changed 13 years ago by 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/

comment:4 Changed 13 years ago by mf2k (Frank Schima)

Resolution: invalid
Status: newclosed

comment:5 Changed 13 years ago by wanthalf@…

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

comment:6 Changed 13 years ago by jmroot (Joshua Root)

Resolution: invalid
Status: closedreopened

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

comment:7 Changed 13 years ago by jmroot (Joshua Root)

Summary: libplist: undefined symbols "_PyCapsule_Import"libplist: build failure when /Library/Frameworks/Python.framework is present

comment:8 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:9 Changed 13 years ago by 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?

comment:10 Changed 13 years ago by jmroot (Joshua Root)

Summary: libplist: build failure when /Library/Frameworks/Python.framework is presentlibplist: installs a python module but doesn't depend on python

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.

comment:11 in reply to:  10 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

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)

comment:12 Changed 12 years ago by 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?

comment:13 Changed 12 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.