verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
govg has quit [Ping timeout: 256 seconds]
govg has joined #mlpack
KTL has joined #mlpack
govg has quit [Remote host closed the connection]
KTL has quit [Ping timeout: 256 seconds]
KTL has joined #mlpack
KTL has quit [Ping timeout: 250 seconds]
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#46 (master - 2eddaf1 : Ryan Curtin): The build has errored.
< naywhayare>
zoq: it seems like with a23e498, if I use clang on linux, it'll try to use -stdlib=libc++ even though the system libc is libstdc++
< zoq>
naywhayare: hm, okay
< naywhayare>
it seems like a better approach might be to figure out if the system default library is libstdc++ or libc++, and then use that... I guess I don't understand why the compiler on OS X (and soon FreeBSD) doesn't default to -stdlib=libc++ when the system standard is libc++
< naywhayare>
but I don't work on OS X and I suspect the situation may be more complicated than what I read there (hence the -stdlib=libc++ patches)
< zoq>
This is absolutely true, I would completely remove the link against libstdc++ or libc++ block. But the comment says we need to link against libstdc++ or libc++ "(at least on some systems)".
< naywhayare>
hmm... let me dig into why that was put there in the first place
< naywhayare>
maybe it's something that I did without really understanding what I was doing since I don't ever use libc++...
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#50 (master - a23e498 : Marcus Edel): The build passed.
< naywhayare>
found with "git log -S'# If using clang' -- CMakeLists.txt"; cool functionality
< naywhayare>
now I need to figure out why I did that...
< zoq>
It fails on OSX Lion
< naywhayare>
maybe, is this a result of homebrew? i.e. if homebrew is distributing packages built against libc++ but the system has packages built with libstdc++ (or vice versa)?
< syrius>
i think most things built on the system are libc++ by default
< syrius>
my case of link mismatching was when linking mlpack to a dll that linked to Qt, which was compiled against libstdc++
< naywhayare>
hm, I found an IRC message I sent saying that I fixed -Wall on clang
< naywhayare>
but can't find a reason anywhere for adding stdlib=libc++
< syrius>
I did see you had in the CMake to specifically add std=libstdc++ if clang was used. i ended up removing that iirc
< syrius>
err, i meant stdlib
< naywhayare>
yeah, I can't figure out precisely why I did that
< naywhayare>
I always try to enter descriptive commit messages but they often don't help all that much a year later :(
< syrius>
heh
< zoq>
Is there a problem to link against libc++ if HAS_LIBCXX11 is true on linux when using clang?
< naywhayare>
either way, it sounds like we can't completely depend on the compiler to link against the correct stdlib
< naywhayare>
yeah, so the problem is in ABI differences. for instance, if libmlpack.so is linked against libc++.so and I build something against the default system libstdc++.so, these two stdlibs have different std::string ABIs (although the API is compatible)
< syrius>
yep
< naywhayare>
so if I then call an mlpack method that takes a std::string, my libstdc++-linked program passes something of the wrong size/alignment to libmlpack.so which expects the std::string from libc++.so, and disaster happens
< syrius>
yeah, that was the first thign we ran into when compiling on osx :) i spent a good day or two trying to figure out what was going on
< naywhayare>
this is the same type of reason that I just created the 'arma_config_check.hpp' file to figure out when the user has built libmlpack.so without ARMA_64BIT_WORD but then links something against mlpack with ARMA_64BIT_WORD: in those cases, uword has different types in libmlpack.so and in the user's program
< naywhayare>
yeah
< naywhayare>
I think it took me a couple days the first time I saw it too
< naywhayare>
I learned a lot as a result of all that digging though, so maybe it was a good thing overall :)
< syrius>
yeah, me too
< naywhayare>
although it looks like I've done something wrong with arma_config_check.hpp, because now it seems to want to rebuild all of libmlpack.so no matter what I do, so I need to figure that out...
< zoq>
Yeah, I see the same problem on FreeBSD on OSX it builds as always
< naywhayare>
so it sounds to me like on OS X Lion, we need to specify stdlib=libc++ manually; but do we need to do this on Mavericks too?
< naywhayare>
from what I've read, Mavericks defaults to stdlib=libc++, so I would think it's not necessary, but I don't have a system to test with to be sure
< zoq>
It works with mavericks and yosemite
< zoq>
I guess mountain lion and lion is the problem
< syrius>
isn't that 10.6?
< zoq>
lion is 10.7mountain lion is 10.8
< zoq>
Maybe we can use CMAKE_COMPILER_IS_GNUCXX
< naywhayare>
how would we use that? does g++ have to have -stdlib=libc++ set too? (I don't completely understand the scope of the problem)
< zoq>
It doesn't solve the problem, maybe we should remove the block and let the user specify the right lib if a problem encounters; I think this is what vowpal_wabbit does
< naywhayare>
I try not to make a habit of following John Langford's code for software engineering advice :)
< naywhayare>
let me dig into what's being done there to understand
< naywhayare>
yeah, it looks like they just have a --enable-libc++ argument; maybe that's the right thing to do here (in the CMake way, I guess, -D ENABLE_LIBCXX or something)
< zoq>
That's probably the best solution
< naywhayare>
do you want to make that change, or should I?
< zoq>
If your time permits :), if not I'll do it later
< naywhayare>
okay; I'm a bit busy with other stuff... so, if I get to it, it'll probably be Monday or so
< naywhayare>
still behind on a couple other bugs that need answering
< zoq>
oh, okay, in this case
< zoq>
Not sure it we need to add a new option maybe -DCMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++" is enough?
< naywhayare>
-std=c++11 should be enabled anyway with the CMake/CXX11.cmake script, but otherwise, yeah, that should work fine
< naywhayare>
so I guess we should just add documentation to the build page or something like that and remove the code that modified the -stdlib option entirely
< zoq>
sounds like a good plan
< naywhayare>
I suppose we could try and catch the OS X Lion and Mountain Lion cases and append it automatically in those cases, if you wanted, but you and syrius are the experts there and not me
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#51 (master - 845367e : Ryan Curtin): The build passed.