Opened 9 years ago
Closed 9 years ago
#49449 closed defect (fixed)
pymol: error: no type named 'shared_ptr' in namespace 'std'
Reported by: | kathryncole | Owned by: | howarth.at.macports@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt) | |
Port: | pymol |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
I am unable to install Pymol. I upgraded my MacPorts, did sudo install, and sudo clean, but I am getting the following error:
Error: org.macports.destroot for port pymol returned: command execution failed Please see the log file for port pymol for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_pymol/pymol/main.log
I searched the previous tickets, and see that there have been similar reports, but I am unsure of the best/ most current solution. Thank you for your help!
Attachments (5)
Change History (17)
Changed 9 years ago by kathryncole
comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Owner: | changed from macports-tickets@… to howarth.at.macports@… |
Port: | pymol added |
Summary: | Error installing Pymol → pymol: error: no type named 'shared_ptr' in namespace 'std' |
The error in the log is:
error: no type named 'shared_ptr' in namespace 'std'
I think this error means the port requires C++11.
The log also shows this is on OS X 10.8, which uses libstdc++ by default which does not support C++11.
The current MacPorts solution to this type of problem is to include the cxx11 portgroup by writing:
PortGroup cxx11 1.0
after the PortSystem line in the portfile. This will cause the user to be directed to a web page that informs them how they can resolve the problem.
comment:2 Changed 9 years ago by howarth.at.macports@…
This change seems to have been introduced in http://sourceforge.net/p/pymol/code/4133/tree//trunk/pymol/layer2/ObjectMolecule.h?diff=50c0fc56e88f3d0bdf694277:4132 so a bug report should be filed upstream.
comment:3 Changed 9 years ago by howarth.at.macports@…
Filed https://sourceforge.net/p/pymol/bugs/171/ to report this upstream.
comment:4 Changed 9 years ago by howarth.at.macports@…
Can someone on 10.7 or 10.8 test the attached Portfile.diff and associated osx108-no-cxx11.patch?
Changed 9 years ago by howarth.at.macports@…
Attachment: | osx108-no-cxx11.patch added |
---|
patch to avoid unsupported c++11 code on 10.8 or earlier
comment:5 Changed 9 years ago by howarth.at.macports@…
The proposed fix ix incomplete as the build on 10.7 with Xcode 4.6's clang still fails with...
:info:destroot layer2/AtomInfo.cpp:1166:12: error: no member named 'copy_n' in namespace 'std'; did you mean 'copy'? :info:destroot std::copy_n(u, 6, I->get_anisou()); :info:destroot ~~~~~^~~~~~ :info:destroot copy :info:destroot /usr/include/c++/4.2.1/bits/stl_algobase.h:389:5: note: 'copy' declared here :info:destroot copy(_InputIterator __first, _InputIterator __last, :info:destroot ^ :info:destroot layer2/AtomInfo.cpp:1166:7: error: no matching function for call to 'copy' :info:destroot std::copy_n(u, 6, I->get_anisou()); :info:destroot ^~~~~~~~~~~ :info:destroot /usr/include/c++/4.2.1/bits/stl_algobase.h:389:5: note: candidate template ignored: deduced conflicting types for parameter '_InputIterator' ('float *' vs. 'int') :info:destroot copy(_InputIterator __first, _InputIterator __last, :info:destroot ^ :info:destroot layer2/AtomInfo.cpp:1199:10: error: no member named 'copy_n' in namespace 'std'layer1/CGO.cpp:; did you mean8535: 'copy'? :info:destroot std::copy_n(src->anisou, 6, dst->get_anisou()); :info:destroot ~~~~~^~~~~~ :info:destroot copy :info:destroot /usr/include/c++/4.2.1/bits/stl_algobase.h:389:5: note: 'copy' declared here :info:destroot copy(_InputIterator __first, _InputIterator __last, :info:destroot 5: warning: expression result unused ^ :info:destroot layer2/AtomInfo.cpp:1199:5: error: no matching function for call to 'copy' :info:destroot std::copy_n(src->anisou, 6, dst->get_anisou()); :info:destroot ^~~~~~~~~~~ :info:destroot /usr/include/c++/4.2.1/bits/stl_algobase.h:389:5: note: candidate template ignored: deduced conflicting types for parameter '_InputIterator' ('float *' vs. 'int') :info:destroot copy(_InputIterator __first, _InputIterator __last, :info:destroot ^ :info:destroot [-Wunused-value] :info:destroot CGO_read_int(pc); :info:destroot ^~~~~~~~~~~~~~~~ :info:destroot layer1/CGO.h:34:26: note: expanded from macro 'CGO_read_int' :info:destroot #define CGO_read_int(p) (*((int*)((p)++))) :info:destroot ^~~~~~~~~~~~~~~~ :info:destroot 4 errors generated.
comment:6 Changed 9 years ago by howarth.at.macports@…
Using libc++ isn't a viable option prior to OS X 10.9. The initial libc++ support was only introduced in OS X 10.7 and the c++-11 support was not fully complete until the OS X 10.9 when Apple switched the system default c++ library. So you really can't depend on all of the features and functionality of c++-11 being present in the libc++ of 10.7/10.8. Unlike FreeBSD, OS X has no libcxxrt shim library (https://wiki.freebsd.org/NewC++Stack) to attempt to bridge the ABI differences in the two c++ libraries. This is why you will find that fink, MacPorts, etc all build their open source packages with libstdc++ up to OS X 10.8 and then completed switched over to libc++ starting with OS X 10.9.
comment:7 Changed 9 years ago by howarth.at.macports@…
Upstream is recommending that we build pymol svn with -stdlib=libc++ passed on CXXFLAGS on 10.7/10.8 (which means that 10.6 and earlier won't be able to build pymol unless we use la recent lvm.org clang/libc++). This happens to work at the moment because 1) python isn't built against c++ so there is no ABI issues and 2) pymol currently doesn't directly link to any code built with c++. IMHO, this is a bit fragile in the long run but will work for now on 10.7/10.8. The approach could potentially break later if upstream keeps expanding the usage of c++-11 features and eventually runs into missing c++-11 support in the early system libc++ of 10.7/10.8.
comment:8 Changed 9 years ago by kathryncole
I just tried:
sudo port install pymol -stdlib=libc++
which failed, so I ran sudo port clean pymol and tried the above command again, but received the following error:
Error: org.macports.destroot for port pymol returned: command execution failed
I attached the log file.
comment:9 Changed 9 years ago by howarth.at.macports@…
The attached Portfile.diff adds -stdlib=libc++ when the clang compilers are in use. It also drops support for FSF gcc variants prior to gcc 4.7 to insure that those variants have c++-11 support going forward.
comment:10 Changed 9 years ago by howarth.at.macports@…
The attached Portfile.diff and pymol_no_cxx11.patch patch is the upstream fix to properly address this problem so that older OS X releases (prior to 10.9) can continue to build against libstdc++. Tested on 10.7 and 10.11.
Changed 9 years ago by howarth.at.macports@…
Attachment: | Portfile.diff added |
---|
Portfile diff to properly address c++11 issue for older OS X releases using upstream patch
Changed 9 years ago by howarth.at.macports@…
Attachment: | pymol_no_cxx11.patch added |
---|
Upstream fix to properly address lack of c++11 support in legacy libstdc++ of earlier OS X
comment:11 Changed 9 years ago by howarth.at.macports@…
comment:12 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
The patch to setup.py seems to base its decision on whether to use C++11 features on whether the OS X version is 10.9 or greater. This is not necessarily correct; it is possible to use libc++ on older systems which will give them C++11 support so you should find a more accurate way to determine if C++11 support is available.
I assume the patch you've attached here has been included in the upstream repository and is superseded by the update in #49666 so I committed that instead of this in r142439.
main.log