Hey, >> I found the cause: In the Boost.numpy CMakeLists.txt, there is this: >> >> https://github.com/tsmithe/Boost.NumPy/blob/34ace9d01efb7a9cf0fe421b86c78400e9632f65/CMakeLists.txt#L50 >> >> Changing the 'SHARED' to 'STATIC' on non-Windows fixes the problem (or >> pass LIBRARY_TYPE accordingly to CMake). However, I wonder why this >> succeeds on other (Ubuntu) machines? Is there a system-wide static >> libboost-numpy available? > > Thanks! That is very odd.. I just checked, and the only static lib file > on my system is the one produced in the build tree for PyViennaCL. And > if you look at > > https://github.com/tsmithe/Boost.NumPy/blob/34ace9d01efb7a9cf0fe421b86c78400e9632f65/libs/numpy/src/CMakeLists.txt#L1 > > then I've commented out ${LIBRARY_TYPE}, so I don't know where the > effect would come from.. Anyway, I'll clean up that CMakeLists.txt.
Argl, the reason is that I had to do a manual clone of your Boost.NumPy repo and did not change the branch. I don't think it's good to have a patched repo for Boost.NumPy around... > Any ideas about the solver bug? It seems to compute the norm of the RHS > and then stop -- for some reason, it computes the norm as 0 in > linalg/gmres.hpp (and I don't think that the norm of that example vector > is 0!).. Still searching. The build process is so awfully slow, it's killing productivity. It takes me minutes to just get a compiler error if something was wrong... > I've also remembered that my own code to compute vector norms using > scheduler calls doesn't work, and that seems to be because I'm building > the expression tree in that case as I do for all other expressions at > the moment, like this: > > Assign(Scalar, Norm_2(Vector)) > > but there doesn't seem to be functionality for that kind of scalar > expression in the scheduler, so that needs fixing. But I'm not sure that > the two issues are related. That might be the cause, because norms are essential in the iterative solvers. > Finally, you can improve recompilation speeds using ccache, but alas I > think it will remain a limitation that standard parallel builds do not > work, thanks to Python's distutils. We need to Python's distutils as much as possible and only expose the very least amount of targets. libviennacl would certainly be *the* solution to this problem. Best regards, Karli ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/viennacl-devel
