These are chat archives for symengine/symengine

14th
Nov 2015
Ondřej Čertík
@certik
Nov 14 2015 02:51
@bluescarni I see, thanks for the feedback. I wonder if there are any warnings or memory checkers in come compilers like clang that would catch issues like returning s.
Francesco Biscani
@bluescarni
Nov 14 2015 02:58
@certik I am not sure. Maybe clang's address and/or memory sanitizers are able to deal with such a situation, but I never actually investigated this specific case.
Isuru Fernando
@isuruf
Nov 14 2015 03:02
@certik, about symengine/symengine.py#23, do you have access to a Mac to check some things?
Btw, it's easy to reproduce in Travis-CI, https://travis-ci.org/isuruf/symengine.py/jobs/90916705
Ondřej Čertík
@certik
Nov 14 2015 03:15
@isuruf I have one at work, but it doesn't work. However I talked with Nate today and suggested him to try to use the following two options: CMAKE_INSTALL_RPATH and CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON
That should fix it.
Then once we figure out a fix, and we can think how to properly incorporate it.
Isuru Fernando
@isuruf
Nov 14 2015 03:16
CMAKE_INSTALL_RPATH_USE_LINK_PATH is on by default
for symengine.py
Ondřej Čertík
@certik
Nov 14 2015 03:16
The CMAKE_INSTALL_RPATH should point into the directory where the Python library is.
that should fix it.
(it might not be the right fix, but right now we are just trying to figure out any fix)
@bluescarni the reason I am asking is that right now symengine should be safe. If we allow to return references, then we have to be a lot more careful.
Isuru Fernando
@isuruf
Nov 14 2015 03:26
I think this has to do with conda python's install_name, which is just libpython3.4m.dylib instead of using @rpath/libpython3.4m.dylib or full path
Ondřej Čertík
@certik
Nov 14 2015 03:54
That's fine.