Fedora 22 install problem

[rmurray2]

Trying to install MOE on Fedora 22.

After running setup.py, it starts building OK, then I get this error:

[ 40%] Building CXX object CMakeFiles/OPTIMAL_LEARNING_PYTHON_BUNDLE.dir/gpp_python_common.cpp.o
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp: In member function ‘bool optimal_learning::RandomnessSourceContainer::SetNormalRNGSeedPythonList(const boost::python::list&, const boost::python::list&)’:
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp:131:171: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
OL_ERROR_PRINTF("NORMAL RNG SEEDING ERROR: len(seed_list) = %lu, len(seed_flag_list) = %lu, normal_rng_vec.size() = %lu\n", seed_list_len, seed_flag_list_len, num_threads);
^
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp:131:171: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘int’ [-Wformat=]
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp:131:171: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘optimal_learning::IdentifyType::type {aka int}’ [-Wformat=]
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp:139:28: error: inconsistent deduction for ‘auto’: ‘long int’ and then ‘int’
for (auto i = 0l, size = num_threads; i < size; ++i) {
^
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp: In member function ‘void optimal_learning::RandomnessSourceContainer::PrintState()’:
/home/rm/MOE/moe/optimal_learning/cpp/gpp_python_common.cpp:159:38: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘std::vector<optimal_learning::NormalRNG>::size_type {aka unsigned int}’ [-Wformat=]
std::printf("NormalRNG %lu:\n", i);
^
CMakeFiles/OPTIMAL_LEARNING_PYTHON_BUNDLE.dir/build.make:77: recipe for target 'CMakeFiles/OPTIMAL_LEARNING_PYTHON_BUNDLE.dir/gpp_python_common.cpp.o' failed
make[2]: *** [CMakeFiles/OPTIMAL_LEARNING_PYTHON_BUNDLE.dir/gpp_python_common.cpp.o] Error 1
CMakeFiles/Makefile2:132: recipe for target 'CMakeFiles/OPTIMAL_LEARNING_PYTHON_BUNDLE.dir/all' failed
make[1]: *** [CMakeFiles/OPTIMAL_LEARNING_PYTHON_BUNDLE.dir/all] Error 2
Makefile:75: recipe for target 'all' failed
make: *** [all] Error 2
error: [Errno 2] No such file or directory: '/home/rm/MOE/moe/build/GPP.so'

And the dirs not found in CMakeCache.txt:

//The directory containing a CMake configuration file for Boost.
Boost_DIR:PATH=Boost_DIR-NOTFOUND
...
//Path to a library.
PYTHON_LIBRARY_DEBUG:FILEPATH=PYTHON_LIBRARY_DEBUG-NOTFOUND

Any idea what the issue might be?

[suntzu86]

Sorry I've been gone for so long! See: #448 for details.

I believe those dirs being not found is ok.

As for the error in your compilation, that looks like a bug. Can you tell me what compiler/version you're using? Can you let me know what std::size_t is and what the type of std::vector::size is on your compiler?

Anyway, I THINK the issue is:

decltype(seed_flag_list_len) num_threads = normal_rng_vec.size();
  for (auto i = 0l, size = num_threads; i < size; ++i) {
...

So i has type long int by declaration. And size wants to have the type of num_threads, which is the type of vector::size, which is usually std::size_t. Whew, a mouthful.

On yours, it seems like that latter type is coming out as an int. I guess on my compilers, this was coming out consistently. The fix should be to change cpp/gpp_python_common.cpp line 139 to:

  for (auto i = 0l; i < num_threads; ++i) {

In fact I'm honestly not sure why I created a separate variable called "size" just to copy the value :/ It is also possible that I didn't see an error before b/c my compiler was automatically optimizing this out.

[rmurray2]

Thanks so much for your response; your suggestion worked!

-- The C compiler identification is GNU 5.1.1
-- The CXX compiler identification is GNU 5.1.1

[suntzu86]

Cool! Glad that worked. Oh gcc 5... yeah I haven't really worked with gcc 5 yet; I've been using icc for my MOE stuff. I know gcc 5's templating stuff (including handling of auto) got some feature enhancements which probably required it to be more strict on stuff like this. Either that or gcc 4 should have been failing too.

Would you mind making a little PR with that change? Or I can do it :)