Opened 14 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 14 years ago by jmroot (Joshua Root)
Owner: | changed from macports-tickets@… to rmstonecipher@… |
---|---|
Port: | libplist added |
comment:3 Changed 14 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 14 years ago by mf2k (Frank Schima)
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:5 Changed 14 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 14 years ago by jmroot (Joshua Root)
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Picking up stuff in /Library instead of the equivalent in ${prefix} is not OK.
comment:7 Changed 14 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 14 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 14 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 follow-up: 11 Changed 13 years ago by jmroot (Joshua Root)
Summary: | libplist: build failure when /Library/Frameworks/Python.framework is present → libplist: 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 Changed 13 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):
comment:12 Changed 13 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: | reopened → closed |
Please remember to fill in the Port field and cc the maintainer.