14:32 < aditya__> hi this is aditya,after $ make install using mlpack_knn --help shows an error can anyone help me please.

14:36 < zoq> aditya__: Hello, what does the error say?

14:37 < aditya__> segmentation fault (core dumped)

14:41 < zoq> Only for the knn executable? Btw. which version do you use?

14:42 < aditya__> I use mlpack-2.1.1

14:43 < aditya__> I did not check for all i will check in a min

14:45 < aditya__> yes sir it shows segmentation fault for every executable

14:46 < rcurtin> do you have multiple versions of mlpack installed on your system?

14:58 < aditya__> firstly i downloaded by direct command but it shows error as dependencies are not installed.Then i seperatelly installed dependencies and later i installed by direct command

15:07 < zoq> I'd expected that LD_LIBRARY_PATH is not set but it doesn't sound like that's the case.

15:18 < rcurtin> aditya__: if you upgraded core libraries on your system after building mlpack then you will probably need to rebuild mlpack against the new libraries

15:19 < rcurtin> and also make sure that there is no other libmlpack.so floating around on your system, that could also cause a segfault

15:20 < aditya__> so can i delete all and rebliud

15:26 < rcurtin> aditya__: yes, I would suggest that as a first step since I don't know much about your situation

15:27 < rcurtin> it might be easier to just install mlpack through your distribution's package manager, i.e. "apt-get install libmlpack-dev"

15:32 < kakarot> aditya, do you still have the issue?

15:32 < kakarot> I faced the issue a while ago and got it fixed

15:36 < kakarot> echo "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/" >> ~/.bashrc

15:36 < kakarot> had solved the issue for me, rather than "export LD_LIBRARY_PATH=/usr/local/lib/" in the docs

15:37 < kakarot> it worked the first time, but started seg faulting later, appending it took care of it for subsequent runs

15:37 < aditya__> thanks 1 min i will try.

15:46 < kakarot> rcurtin, I cam across one of your papers on dual trees, havent covered it fully, looks really interesting. Great acknowledgement on the cats though :D Cheers!

15:47 < rcurtin> hah, I am glad someone noticed :)

15:48 < rcurtin> your LD_LIBRARY_PATH command is actually safer (it preserves any old LD_LIBRARY_PATH) so I think I will update the readme

15:49 < aditya__> kakrot thanks it worked!!

15:50 < rcurtin> I'm surprised, usually a missing LD_LIBRARY_PATH will say something like 'libmlpack.so not found' or similar

15:50 < rcurtin> I am willing to bet that on both your systems, there is a stray libmlpack.so of a different version floating around

15:53 < kakarot> I pretty much had a fresh install of mlpack that was built from source and I only went with the latest stable version. If I do get another ubuntu machine to try it on, I'll let you know how it works out there :)

15:55 < aditya__> i have installed mlpack-2.1.1 earlier

16:30 < travis-ci> mlpack/mlpack#1723 (master - 4812549 : Ryan Curtin): The build passed.

16:30 < travis-ci> Change view : https://github.com/mlpack/mlpack/compare/eff46c953238...48125493b947

16:30 < travis-ci> Build details : https://travis-ci.org/mlpack/mlpack/builds/188891191

19:54 < rcurtin> heh heh, I spend the morning telling people that extra versions of libmlpack.so can cause problems if LD_LIBRARY_PATH isn't set right...

19:54 < rcurtin> and then I spend the afternoon debugging a very strange problem on my system only to find after a few hours that LD_LIBRARY_PATH is not set right and there's an extra version of libmlpack.so in /usr/local/lib/...

19:55 < rcurtin> I should listen to my own advice! :)

19:58 < zoq> :) it would be much easier if the error message is more descriptive, "segmentation fault" ....

19:59 < rcurtin> yeah; in my case I was building some python bindings automatically and found that they were linked against a version of libbfd that doesn't exist

19:59 < rcurtin> I ended up spending an hour reading about debian's policy of not linking dynamically to libbfd and wondering what was wrong with cython

20:00 < rcurtin> and then I realized that the python binding so was linked against /usr/local/lib/libmlpack.so... which was linked against the no-longer-existent libbfd.so

20:00 < rcurtin> I think that maybe I will have to look into the debian package a little bit---if it ships with a debug version, which will be linked against libbfd.so, it'll need to either link statically against libbfd or be rebuilt every time binutils is updated

20:00 < rcurtin> but I don't think it does ship a debug version, so I think there's no issue

20:01 < zoq> oh, sounds like a really "nice" "bug" hunt

20:02 < rcurtin> I don't mind too much; always a good opportunity to learn more about runtime and compile-time linking :)