Re: move entirely to CMakefiles for building MXNet, drop Makefiles

2018-03-07 Thread Zha, Sheng
You can set rpath to $${ORIGIN} to make the path where the libmxnet.so resides a path to look up. -sz - Sent by my thumb > On Mar 7, 2018, at 7:45 AM, Pedro Larroy wrote: > > About libomp.so > > This is giving me some problems when creating a pip package for

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

2018-03-07 Thread Pedro Larroy
About libomp.so This is giving me some problems when creating a pip package for installing on Jetson. I'm thinking that in this case would be better to compile with -fopenmp. I tried adding libomp.so to the pip package next to libmxnet.so and still I couldn't load the library... Any ideas?

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

2018-03-06 Thread Eric Xie
We want as few dependencies as possible. CMake alone is enough trouble for our users. We don't want to burden them with other stuff. On 2018/03/06 17:21:15, kellen sunderland wrote: > Short term solution sounds good to me Chris. Converting the CI should be >

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

2018-03-06 Thread kellen sunderland
Short term solution sounds good to me Chris. Converting the CI should be pretty easy. One thing we should keep in mind is that there's going to be a bunch of doc's we'll have to update. Warning, slight thread hijack ahead: As a more long term change I was wondering if we had considered using

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

2018-03-06 Thread Chris Olivier
Here is discussion: https://github.com/apache/incubator-mxnet/issues/8702 On Tue, Mar 6, 2018 at 9:14 AM, Chris Olivier wrote: > This was agreed upon some time ago in a github issue thread, unless there > are new objections to it. > > As far as I know, it's just a matter

Re: move entirely to CMakefiles for building MXNet, drop Makefiles

2018-03-06 Thread Chris Olivier
This was agreed upon some time ago in a github issue thread, unless there are new objections to it. As far as I know, it's just a matter of someone putting in the work to add more functionality to cmake or to fuse the two builds. One solution for the short term might include having the Makefile