Recently PyDSTool has been added as one of system-wide packages for Sage Math Cloud, so I've decided to try it. However, I've got a problem using integrators other than VODE. For example, if I take PyCont_SaddleNode.py, copy & paste its content into IPython notebook and run it, I get following message:
As far as I see, the radau5_temp directory has been created, radau5_SaddleNode_vf.i and SaddleNode_vf.c have been generated, but no compiled code has been generated.
So, could you help me to figure out what went wrong and what should be done in order to fix it? Thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, it seems that I've managed to use the latest version of PyDSTool from GitHub (I see this because of the path from which package is loaded; pyDSTool.version shows something that looks like NumPy version) and now I don't have the error that I've described earlier, but there's a new one:
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start':
/build/buildd/glibc-2.21/csu/../sysdeps/x86_64/start.S:114: undefined reference to `main'
collect2: error: ld returned 1 exit status
This error prevents further execution of IPython notebook. I've attached the full log to the post.
Same problem like in this issue on Github: gfortran call doesn't have "-shared" option and tries to build executable instead of shared lib. I still can't reproduce this bug in my environments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, finding compiler options environment variable and changing it might fix this issue? Or is it deeper?
If you have an account and want to take a look, I can share you my project at Sage Math Cloud.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I see, executing "echo $CFLAGS" and "echo $FFLAGS" in SMC terminal shows empty string in both cases. However, looking at "gcc -v" I see that option --enable-shared is checked (though I was told by someone that this means nothing and it won't automatically tell compiler to make a shared library). I also have no idea why it works this way. Anyway, thank you for your help and for your time!
Also, does compiling external integrator always create such long paths inside build directory? I mean, that part of log
Hi Evgenij, if you have access to the source or know the folk that do, maybe you could try editing utils.py in the main PyDSTool directory in the function extra_arch_arg and, in the same way that '-m32' is added, add '-shared' to both possible returns. We could theoretically add it to the repo ourselves, since I don't think it could do any harm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Rob, thanks for suggestion! I've made changes locally, installed PyDSTool and after that using Radau integrator finally worked. I can make it as a pull request at GitHub, should I? (However, I think that changes won't be applied system-wide at SMC until update of package at PyPI)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I've managed to reproduce bug locally (inside "sage -sh"). Sage sets LDFLAGS environment variable to empty string. Python distutils uses it to tune linker command.
(sage-sh) $ env | grep LDF
LDFLAGS=(sage-sh) $ python examples/PyCont_SaddleNode.py
/usr/lib/i386-linux-gnu/crt1.o: In function`_start':/build/buildd/glibc-2.21/csu/../sysdeps/i386/start.S:111: undefined reference to `main'
collect2: error: ld returned 1exit status
error: <...> failed with exit status 1
Thank you Vladimir! I've tried your suggestion (with one modification only - after unsetting LDFLAGS I'm running the PyCont_SaddleNode.py straight from command line without creating new Sage process) and it worked too. Jupyter notebooks, however, still have the same problem, but I think I'll ask SMC support about this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
Recently PyDSTool has been added as one of system-wide packages for Sage Math Cloud, so I've decided to try it. However, I've got a problem using integrators other than VODE. For example, if I take PyCont_SaddleNode.py, copy & paste its content into IPython notebook and run it, I get following message:
As far as I see, the radau5_temp directory has been created, radau5_SaddleNode_vf.i and SaddleNode_vf.c have been generated, but no compiled code has been generated.
So, could you help me to figure out what went wrong and what should be done in order to fix it? Thanks in advance!
On Thu, Jul 02, 2015, Evgenij Gr. wrote:
If possible try to switch to version from github repository. This has
been fixed there, but the fix is not released yet.
--
Regards,
Vladimir Zakharov
Hm, it seems that I've managed to use the latest version of PyDSTool from GitHub (I see this because of the path from which package is loaded; pyDSTool.version shows something that looks like NumPy version) and now I don't have the error that I've described earlier, but there's a new one:
This error prevents further execution of IPython notebook. I've attached the full log to the post.
Same problem like in this issue on Github: gfortran call doesn't have "-shared" option and tries to build executable instead of shared lib. I still can't reproduce this bug in my environments.
So, finding compiler options environment variable and changing it might fix this issue? Or is it deeper?
If you have an account and want to take a look, I can share you my project at Sage Math Cloud.
Unfortunately, I don't have any ideas. Possibly CFLAGS and/or FFLAGS are polluted in your environment. Maybe not..
This is broken gfortran call from your log:
And this is from mine:
Ending flags ("-w" in your case and "-w -m32" in mine) are added by PyDSTool. All others come from environment (setuptools?).
I don't have account at Sage Math Cloud.
As far as I see, executing "echo $CFLAGS" and "echo $FFLAGS" in SMC terminal shows empty string in both cases. However, looking at "gcc -v" I see that option --enable-shared is checked (though I was told by someone that this means nothing and it won't automatically tell compiler to make a shared library). I also have no idea why it works this way. Anyway, thank you for your help and for your time!
Also, does compiling external integrator always create such long paths inside build directory? I mean, that part of log
looks strange for me (but maybe that's because I rarely use gcc and I'm newcomer to PyDSTool and have no experience to compare with).
Hi Evgenij, if you have access to the source or know the folk that do, maybe you could try editing utils.py in the main PyDSTool directory in the function
extra_arch_arg
and, in the same way that '-m32' is added, add '-shared' to both possible returns. We could theoretically add it to the repo ourselves, since I don't think it could do any harm.Hello Rob, thanks for suggestion! I've made changes locally, installed PyDSTool and after that using Radau integrator finally worked. I can make it as a pull request at GitHub, should I? (However, I think that changes won't be applied system-wide at SMC until update of package at PyPI)
Ok, I've managed to reproduce bug locally (inside "sage -sh"). Sage sets LDFLAGS environment variable to empty string. Python distutils uses it to tune linker command.
Unsetting "LDFLAGS" fixed problem for me.
Thank you Vladimir! I've tried your suggestion (with one modification only - after unsetting LDFLAGS I'm running the PyCont_SaddleNode.py straight from command line without creating new Sage process) and it worked too. Jupyter notebooks, however, still have the same problem, but I think I'll ask SMC support about this.