Woah, nice! Thanks for the insight, William :)
Best regards, Marcus On 07/27/2017 03:49 AM, wjohnson wrote: > Hi Luca, > > Thanks so much for the reply. > > My issue turned out to have nothing to do with cmake or loading > external libraries, but reviewing your gr-dab module was greatly > helpful in that I was able to compare what I was doing against a known > working example, so thank you for that. This led me to leave that red > herring alone and identify the real problem. > > It turns out that my issue was instead related to the Python Global > Interpreter Lock (GIL). > > I was able to get matplotlib working by modifying the initialization > code for the python interpreter from: > Py_Initialize(); > .... > > to: > Py_Initialize(); > PyGILState_STATE d_gstate; > d_gstate = PyGILState_Ensure(); > .... > perform python work > .. > PyGILState_Release(d_gstate); > .... > > Presumably, this would be required when calling any python function > from within an OOT C++ module. I don't understand the possible risks > associated with this solution well enough to feel comfortable using it > in production, but as this is only used in a debug environment for me, > it seems to work well enough. > > If anyone is interested in why, see: > https://stackoverflow.com/questions/43692150/python-to-c-to-python-call-flow-causing-segmentation-fault > and > https://stackoverflow.com/questions/4866701/python-pygilstate-ensure-release-causes-segfault-while-returning-to-c-from-p > and > https://docs.python.org/2/c-api/init.html > > > Thanks again. > > > On Wed, 2017-07-26 at 23:34 +0200, Moritz Luca Schmid wrote: >> >> Hi William, >> >> I am not sure, if this is your issue, but it seems as your external >> lib is not found by your cmake. I currently dealt with including some >> external libraries in the gr-dab module too. >> >> I always wrote a Find.cmake file that lets cmake find the path to >> your library header. >> >> Check it out for example the FindFaad.cmake >> <https://github.com/kit-cel/gr-dab/blob/working_branch/cmake/Modules/FindFaad.cmake>. >> You can than find the package (find_package) in your CMakeLists.txt >> of your module and check if it was successfully found. >> >> >> I hope that helps finding your issue >> >> Luca >> >> >> >> On 26.07.2017 23:05, William Johnson wrote: >>> I have been having some difficulty successfully using external >>> libraries in a custom OOT module that I have not been able to >>> understand. >>> >>> I have had this issue with a few different external libraries. The >>> symptom is a segmentation fault when a function in the external >>> library is called. The below example is just representative and a >>> bit circular as we are going from python->c++->python. >>> >>> For this example, I would like to use matplotlib within a C++ OOT >>> module to visualize some data during the debug of my module. I >>> understand that this is not something I would want to do within a >>> gnu radio module during normal usage and that there are other ways >>> to visualize the data. >>> >>> I am using matplotlib.cpp (https://github.com/lava/matplotlib-cpp) >>> for this purpose. This is simply a header file that requires >>> linking to the python libraries. >>> >>> To do this I have: >>> >>> 1. Included matplotlibcpp.h in my /lib folder. >>> >>> 2. In /lib/CMakeList.txt I have added the following: >>> >>> find_package(PythonLibs 2.7) >>> include_directories(${Boost_INCLUDE_DIR} ${PYTHON_INCLUDE_DIRS} ) >>> link_directories(${Boost_LIBRARY_DIRS} ${PYTHON_LIBRARIES} ) >>> ... >>> target_link_libraries( gnuradio-mymodule ${Boost_LIBRARIES} >>> ${GNURADIO_ALL_LIBRARIES} ${PYTHON_LIBRARIES}) >>> >>> >>> 3. Within my general_work function I have added the following (as a >>> test only): >>> >>> #include <cmath> >>> #include "matplotlibcpp.h" >>> namespace plt = matplotlibcpp; >>> ... >>> general_work(... >>> ... >>> // This just creates an interesting figure to plot. >>> int n = 5000; >>> std::vector<double> x(n), y(n), z(n), w(n,2); >>> for(int i=0; i<n; ++i) { >>> x.at <http://x.at>(i) = i*i; >>> y.at <http://y.at>(i) = sin(2*M_PI*i/360.0); >>> z.at <http://z.at>(i) = log(i); >>> } >>> >>> plt::plot(x, y); >>> plt::show(); >>> ... >>> >>> I am able to build successfully but when I run my qa_XYZ.py unit >>> test I get a segmentation fault at the plt::plot(x,y) line. >>> removing these two plt:: lines results in no segmentation fault. I >>> have seen this same behavior when linking with other (not python) >>> libraries for different reasons so I am suspecting that there is >>> some fundamental issue with how I am configuring CMakeLists.txt or >>> what I am trying to do is not possible for some other reason. >>> >>> ---- >>> The following code runs without any issues on the same machine >>> outside of gnuradio. >>> -------------------------------------------------- >>> #include <cmath> >>> #include "matplotlibcpp.h" >>> >>> namespace plt = matplotlibcpp; >>> >>> int main() >>> { >>> // Prepare data. >>> int n = 5000; >>> std::vector<double> x(n), y(n), z(n), w(n,2); >>> for(int i=0; i<n; ++i) { >>> x.at <http://x.at>(i) = i*i; >>> y.at <http://y.at>(i) = sin(2*M_PI*i/360.0); >>> z.at <http://z.at>(i) = log(i); >>> } >>> >>> plt::plot(x, y); >>> plt::show(); >>> } >>> -------------------------------------------------- >>> >g++ test.cpp -I/usr/include/python2.7 -lpython2.7 >>> >>> Any help would be appreciated. >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
