- This topic has 10 replies, 3 voices, and was last updated 4 years, 3 months ago by
.
-
Posts
-
Hi @jlorenze,
I believe it it possible to get it to work without much effort. But there will be bugs in error reporting, because of exceptions that can’t be caught in python 3.6-3.7 because of a lack of multithreading support.
We thus chose not to support it (python 3.6 is now 4 years old anyway), and advise our users to install python 3.8+ on their machines (install can easily be done alongside your officially supported version on linux)Have fun with SofaPython3! 🙂
Do you have any documentation that discusses how to change specify the Python version when you build SofaPython3?
Hi @jlorenze,
I think specifying the exact python executable during the configuration with cmake might do the trick. Try setting the PYTHON_EXECUTABLE flag to /usr/bin/python3.8 (for example). It seems to me that the cmake config process will derive the rest of the dependencies from that by subsecuently calling /usr/bin/python3.8-config to find the right libs to link to, etc.
I’m not 100% sure, but it’s worth the try, I think!
Best
Stefan
We do not document the install of an extra python version on a linux distro because it is already relatively well documented on the net. ([see here for instance](https://hackersandslackers.com/multiple-versions-python-ubuntu/)
Usually the trick is to play with update-alternatives (on ubuntu at least) to set additional python versions.When it comes to how to link with the right python libraries and executables when compiling SofaPython3, that should be relatively well documented in the Readme.md of the plugin.
Don’t forget to install python AND the python development packages! 🙂
EDIT:
One more thing, I do not advise you to change the default version of python on your machine (which is possible to do with update-alternatives). It is better to explicitely set the version you want in CMAKE (Python_EXECUTABLE variable), because some system programs might stop working properly if their default python version is overridden)Oh, yeah to encourage people to upgrade to 3.7 or 3.8 we have set the minimum python version supported to 3.7
To override that you will have to change it in the main CMakeLists.txt, line 68:# Set the minimum python version to 3.7 set(PYBIND11_PYTHON_VERSION 3.7)If you change this value to 3.6 the error message should disappear. Tell me if that works for you!
So that allowed me to successfully run cmake, but now when I try to actually run “make” in the build directory I get the following errors
jlorenze@jlorenze:~/sofa-plugins/SofaPython3/build$ make -j4 [ 3%] Built target Bindings.Sofa.Simulation [ 4%] Building CXX object Plugin/CMakeFiles/Plugin.dir/src/SofaPython3/PythonEnvironment.cpp.o [ 6%] Building CXX object Plugin/CMakeFiles/Plugin.dir/src/SofaPython3/DataHelper.cpp.o [ 7%] Building CXX object Plugin/CMakeFiles/Plugin.dir/src/SofaPython3/PythonFactory.cpp.o [ 9%] Building CXX object Plugin/CMakeFiles/Plugin.dir/src/SofaPython3/Prefab.cpp.o /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp: In member function ‘void sofapython3::PythonEnvironmentData::add(const string&)’: /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp:108:27: error: ‘Py_DecodeLocale’ was not declared in this scope m_argv.push_back( Py_DecodeLocale(data.c_str(), nullptr) ); ^~~~~~~~~~~~~~~ /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp:108:27: note: suggested alternative: ‘PyEval_GetLocals’ m_argv.push_back( Py_DecodeLocale(data.c_str(), nullptr) ); ^~~~~~~~~~~~~~~ PyEval_GetLocals /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp: In static member function ‘static void sofapython3::PythonEnvironment::setArguments(const string&, const std::vector<std::__cxx11::basic_string<char> >&)’: /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp:506:60: error: cannot convert ‘wchar_t**’ to ‘char**’ for argument ‘2’ to ‘void PySys_SetArgvEx(int, char**, int)’ PySys_SetArgvEx( data->size(), data->getDataBuffer(), 0); ^ /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp: In function ‘PyGILState_STATE sofapython3::lock(const char*)’: /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp:534:52: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘id’ auto id = PyGILState_GetThisThreadState()->id; ^~ /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp: In destructor ‘sofapython3::PythonEnvironment::gil::~gil()’: /home/jlorenze/sofa-plugins/SofaPython3/Plugin/src/SofaPython3/PythonEnvironment.cpp:552:48: error: ‘PyThreadState {aka struct _ts}’ has no member named ‘id’ auto id = PyGILState_GetThisThreadState()->id; ^~ Plugin/CMakeFiles/Plugin.dir/build.make:78: recipe for target 'Plugin/CMakeFiles/Plugin.dir/src/SofaPython3/PythonEnvironment.cpp.o' failed make[2]: *** [Plugin/CMakeFiles/Plugin.dir/src/SofaPython3/PythonEnvironment.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... CMakeFiles/Makefile2:442: recipe for target 'Plugin/CMakeFiles/Plugin.dir/all' failed make[1]: *** [Plugin/CMakeFiles/Plugin.dir/all] Error 2 Makefile:132: recipe for target 'all' failed make: *** [all] Error 2Just as a follow up, the reason I am trying to use Python 3.6 is that it is the version compatible with ROS2 Eloquent (running on Ubuntu 18.04). However I actually decided it would be better to just upgrade to Ubuntu 20.04 and use ROS2 Foxy (which will use Python 3.8). So I suppose this thread can be closed out since I no longer need an answer. Thanks for your support with it!
I tried running a simple example with an existing scene that I know works and just include the initialization of a ROS node (i.e. import rclpy and rclpy.init()) in the createScene to check if it was working and I get a SIG 6 SIGABRT error. This seems to be very similar to a crash I also see when trying to use cvxpy in a Sofa.Core.Controller (and for which I have also recently posted to the forum about in post #17072).
Would you advise I create a new post to discuss this issue separately from #17072 or should I just add to that post?
Hi @jlorenze,
good luck with the installation on Ubuntu 20.04!
I think it’s fair to add the issue of the ROS initialization to the discussion in #17072. It is also possible that the issues might disappear/change when using Ubuntu 20.04 (and ROS2 Foxy), right?
Stefan
- You must be logged in to reply to this topic.
