00:23 < nckswt> Hi - I'm having trouble getting MLpack up and running on OS X. I'm using XCode, I've installed mlpack and its dependencies using homebrew, I believe I've properly linked all the dynamic libraries and specified the library search paths, but I get a bunch of un-google-able errors whenever I try to #include <mlpack/core.hpp>

00:25 < nckswt> I think it might be related to boost, but I'm not sure. A bunch of the errors are something like, "Use of undeclared identifier 'nullptr_t'; did you mean nullptr?" and "No member named 'memcpy' in namespace std::__1'; did you mean simply 'memcpy'?"

00:34 < rcurtin> hi nckswt, are you specifying -std=c++11 in your compiler options?

00:34 < rcurtin> (just a first guess. not sure if that's what's going on here)

00:35 < nckswt> yeah - that's one of the things I played with

00:35 < nckswt> sadly, no change at all

00:39 < nckswt> could it be because I'm linking against .dylib files instead of against .so files?

00:42 < rcurtin> no, that shouldn't be the issue

00:42 < rcurtin> can you possibly paste the compilation output to pastebin or something?

00:42 < rcurtin> that might be helpful in figuyring out what is going on

00:42 < rcurtin> since it's C++, it's probably like ten thousand lines long :)

00:43 < nckswt> here's the errors: http://pastebin.com/1TVXDGVa

00:43 < nckswt> I'm just getting back into C++ after several years of python, so it's taking me a bit to get used to the Xcode interface =p

00:44 < rcurtin> hmm... so I am not an OS X expert, but I do have a couple ideas at least

00:45 < rcurtin> so you installed xcode, and then installed mlpack through homebrew?

00:45 < nckswt> yup

00:45 < rcurtin> where did boost come from? xcode/homebrew?

00:46 < nckswt> homebrew - my header search path is configured as "/usr/local/Cellar/boost/1.60.0_1/include"

00:46 < rcurtin> okay

00:46 < nckswt> library search paths are /usr/local/Cellar/mlpack/1.0.12_2/lib and /usr/local/Cellar/boost/1.60.0_1/lib

00:46 < rcurtin> can you compile other C++ programs? like some simple int main() { } type thing?

00:47 < nckswt> yup, no problem compiling there

00:47 < rcurtin> hm, okay

00:47 < nckswt> it's only upon including #include <mlpack/core.hpp>, and the errors seem to come from boost files

00:48 < rcurtin> okay; I didn't see any boost errors, just stuff out of stdlib (//Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception)

00:48 < rcurtin> part of me wonders, but isn't sure, if there is some incompatibility between the compiler you are using and where it is searching for stdlibc++

00:48 < nckswt> ah, I expanded the errors and got some more infor: http://pastebin.com/mCrfCMRf

00:49 < nckswt> how could I check that?

00:49 < rcurtin> hm... which compiler are you using to compile your program?

00:49 < rcurtin> is it the XCode compiler or one you got through homebrew?

00:50 < nckswt> XCode

00:50 < rcurtin> hm, so what happens if you install g++ through homebrew and try to compile with that?

00:50 < rcurtin> ah, also, what version of xcode?

00:51 < nckswt> 7.2

00:51 < nckswt> I'll try compiling outside of Xcode, see what happens

00:51 < rcurtin> yeah; if that works, I think I might have an idea of which direction to debug in

00:52 < nckswt> gcc main.cpp In file included from main.cpp:3: In file included from /usr/local/include/mlpack/core.hpp:171: /usr/local/include/mlpack/core/util/save_restore_utility.hpp:26:10: fatal error: 'libxml/parser.h' file not found #include <libxml/parser.h> ^ 1 error generated.

00:53 < nckswt> oh, wait, I need to set flags

00:53 < rcurtin> yeah, add -I/path/to/include/libxml2/

00:53 < rcurtin> that libxml2 include path was always irritating to get right because some distributions install to /usr/include/libxml2/, some to /usr/include/

00:53 < rcurtin> fortunately, since 2.0.0 there is no more libxml2 dependency :)

00:53 < rcurtin> (hopefully the homebrew guys will get it updated soon. maybe I should poke them)

00:56 < nckswt> okay, now we're getting somewhere: http://pastebin.com/4WRwDsGV

00:57 < rcurtin> ah, you'll just need to add -lmlpack to link against mlpack for those, I think

00:57 < rcurtin> also probably -lxml2 and maybe -lboost_program_options

00:58 < nckswt> so, this? gcc main.cpp -I/usr/include/libxml2 -lmlpack -lxml2 -lboost_program_options

00:58 < nckswt> I get the same result

00:59 < rcurtin> so -lmlpack makes no difference?

00:59 < rcurtin> I would think that libmlpack.dylib would already be on the linker search path... you could also try specifying -L/path/to/dir/ where dir/ contains libmlpack.dylib

01:00 < nckswt> not that I can tell - is that definitely linking against mlpack?

01:00 < nckswt> yeah, I'll try that

01:00 < nckswt> nope, same issue

01:03 < rcurtin> sometimes compilers can be finicky... can you try the -L<stuff> before the -lmlpack?

01:03 < rcurtin> or actually I think you can link directly with -L/path/to/libmlpack.dylib

01:04 < nckswt> so, gcc main.cpp -I/usr/include/libxml2 -L/usr/local/lib/libmlpack.dylib -lmlpack ?

01:04 < rcurtin> you should be able to omit the final -lmlpack

01:05 < nckswt> yeah

01:05 < nckswt> still giving me that same error in boost

01:05 < nckswt> do I need to link against boost somehow?

01:06 < rcurtin> okay... try adding -L/usr/local/lib/libboost_math_tr1.dylib

01:07 < nckswt> http://pastebin.com/gkmiEFW3

01:07 < nckswt> should I worry about those "... is not a directory" warnings?

01:08 < rcurtin> looks like maybe that particular compiler doesn't like the .dylib at the end of the -L calls... maybe try -L/usr/local/lib -lmlpack -lboost_math_tr1

01:09 < rcurtin> (I'm assuming libboost_math_tr1.dylib is in /usr/local/lib; if not, you'll have to add another directory with -L)

01:09 < rcurtin> compilation with C++ is not always very much fun :(

01:09 < rcurtin> in fact I might consider changing "not always" in my statement to "always not"...

01:09 < nckswt> haha

01:09 < nckswt> yup =)

01:10 < nckswt> libboost_math_tr1.dylib is definitely there

01:19 < nckswt> if I just try to compile it with "#include <boost/filesystem.hpp>" instead of "#include <mlpack/core.hpp>", it still fails

01:19 < rcurtin> at the linking stage?

01:19 < nckswt> yup

01:19 < rcurtin> what's the version of the compiler? (gcc --version)

01:20 < nckswt> Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin14.5.0 Thread model: posix

01:20 < rcurtin> ah also if you use g++ instead of gcc, does this make a difference?

01:20 < nckswt> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1

01:20 < nckswt> still linking errors, but less verbose

01:21 < rcurtin> are there any other directories than 4.2.1 in /usr/include/c++?

01:21 < nckswt> oh! I got it! I think

01:21 < nckswt> I had to add -lboost_system-mt

01:22 < rcurtin> oh, okay, so now it compiles without issue

01:22 < rcurtin> now if you switch back to the mlpack example and add -lboost_system-mt to the compilation there, is it also successful?

01:22 < nckswt> checking now

01:23 < nckswt> yes! that worked

01:23 < nckswt> haha, finally!

01:23 < nckswt> thanks a lot for helping me out for practically an hour =)

01:23 < rcurtin> okay, so you can compile from the command-line with gcc

01:23 < rcurtin> sure, no problem :)

01:23 < rcurtin> but we still haven't solved your original issue :)

01:23 < nckswt> yup =)

01:23 < nckswt> checking that now

01:23 < rcurtin> I am concerned that XCode, for some reason, is using a very old libstdc++

01:24 < rcurtin> this is supported by the fact that gcc is using "--with-gxx-include-dir=/usr/include/c++/4.2.1"

01:24 < rcurtin> that to me means that the libstdc++ is the one that shipped with gcc 4.2.1, which was like eight years ago and didn't have c++11 support (or even c++0x support as it was called at the time)

01:24 < rcurtin> does "g++ --version" give a different version?

01:25 < nckswt> that gives me:

01:25 < nckswt> Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin14.5.0 Thread model: posix

01:25 < nckswt> so, no

01:25 < nckswt> exact same

01:25 < rcurtin> okay

01:26 < rcurtin> but when I look at the output further, I see that that's the compiler that shipped with XCode, not one from homebrew

01:26 < rcurtin> (given the "--prefix=/Applications/Xcode.app/....")

01:26 < rcurtin> so is it possible that just modifying the compilation configuration in Xcode could fix the original issue?

01:27 < rcurtin> (that is, ensuring that Xcode is running the exact same command for compilation that you just did from the command line)

01:27 < nckswt> yeah, let me try to figure out how to select the other compiler from within xcode

01:28 < nckswt> hmm, interesting - g++ works, but gcc doesn't when compiling from command-line

01:28 < rcurtin> gcc in most cases will be trying to compile the code as C, not C++

01:28 < nckswt> ahh

01:28 < rcurtin> actually sorry I think I misspoke, hang on

01:29 < nckswt> nono, I think you're right - it had been a while, but that's what I remember

01:30 < rcurtin> yeah, I was incorrect; gcc and g++ will both compile as C or C++ (depending on the given code)

01:30 < rcurtin> but the primary difference is that g++ will automatically link against stdlibc++ whereas gcc will not

01:30 < nckswt> ah, okay. good to know!

01:30 < rcurtin> a billion more details in this stackoverflow thread... http://stackoverflow.com/questions/172587/what-is-the-difference-between-g-and-gcc

01:31 < nckswt> so, in Xcode itself, I'm using "Default compiler (Apple LLVM 7.0)"

01:31 < nckswt> which is exactly what I'm using when I call g++, right?

01:32 < rcurtin> I think that would be the same... do you have any way of getting the exact command called when you invoke the compiler?

01:32 < rcurtin> i.e. do the compilation logs print the command used too, maybe?

01:34 < nckswt> I believe this is it: http://pastebin.com/2Q5qMMUH

01:35 < rcurtin> wow that is quite a long call :)

01:36 < rcurtin> two things:

01:37 < rcurtin> if you run "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version", do you get the same version as "gcc --version"?

01:37 < rcurtin> and, is it possible to remove the "-std=c++11" option and see if that does anything?

01:37 < rcurtin> I have to step out for a moment... I'll be back in a few

01:37 < nckswt> yup, I get the same version

01:38 < nckswt> and I'll have to head out in about 10 minutes, so I'll look into the problem and, if I can find a good solution, I'll posted it on the github page. looks like it's more related to boost than it is to mlpack, at least!

01:39 < nckswt> I feel like I'm going to miss the days of "pip install PACKAGE" being all I need to do to use a library =p

01:48 < nckswt> alright, I'm logging off IRC now. thanks again for all the help - sorry we didn't track it down yet! you can find me at nckswt@gmail.com if you want to chat more. thanks!