ARMv7l installation from source - compiling external libraries

[codedhard]

I'm following instructions: https://gist.github.com/rhyolight/15b8454780424f690d00 . I trying to install nupic from the source on raspberry pi (32bit), because I could not find an image for running on 64 bit. Platform: armv7l-unknown-linux-gnueabihf. I know this build is not officially supported.

I do have files in: /home/ubuntu/nupic.core/external/linux32armv7/bin/libapr-1.a /home/ubuntu/nupic.core/external/linux32armv7/libapr-1.a /usr/local/apr/lib/libapr-1.a

cmake -DLIB_STATIC_APR1_LOC="/usr/local/apr/lib/libapr-1.a" made no difference

It fails on installing APR. Command "make j1". make[1]: *** [external/CMakeFiles/Apr1StaticLib.dir/all] Error 2

config.log:

configure:5381: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.

gcc: error: unrecognized argument in option '-mtune=generic'
gcc: error: unrecognized command line option '-m32'
...

[rhyolight]

@codedhard You are not the only person working on 32b compilation, see @pettitda and #956. Maybe you guys can collaborate on this?

[vitaly-krugl]

As of recent changes, the sources of the externals (apr1, etc.) are packaged in nupic.core repor as tar archives and built in place. LIB_STATIC_APR1_LOC is set by external/Apr1Lib.cmake to the path where the static lib will be located after nupic.core cmake system builds it.

It also looks like your gcc compiler/toolchain version doesn't support some compiler options that are used by the nupic.core build system. Which gcc version are you using?

[codedhard]

@vitaly-krugl I have "gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010"

Then I changed, that was to test on other version sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 80

Results:

gcc (Ubuntu/Linaro 4.8.5-1ubuntu1) 4.8.5
gcc: error: unrecognized command line option '-qversion'
gcc: error: unrecognized argument in option '-mtune=generic'

gcc: note: valid arguments to '-mtune=' are: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a15 cortex-a5 cortex-a53 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m0plus cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 cortex-r7 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale

gcc: error: unrecognized command line option '-m32'

The correct options: -mtune=cortex-a7 or cortex-a8 -m32: this needs to be removed on ARM

[vitaly-krugl]

@codedhard, it looks like you would need to set the values conditionally for the ARM compiler in https://github.com/numenta/nupic.core/blob/master/CommonCompilerConfig.cmake. There are a couple of places there that reference "-m${BITNESS}" and one with "-mtune=generic"

[codedhard]

@vitaly-krugl Thanks for point to the correct file and variables.

This is my fixed the problem (lazy way). if(NOT ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")

This one was giving me an empty string. message( STATUS "Architecture: ${ARCHITECTURE}" )

I will try to compile tomorrow, to test for any other errors.

Do you want me to upload the changed script?

[rhyolight]

Do you want me to upload the changed script?

@codedhard Yes, but better yet, you could update our wiki?

[codedhard]

I did tried to recompile many times. Logs don't show any bad errors. Did I missed to install something. Similar closed issue was: https://github.com/numenta/nupic.core/issues/954 ...

/tmp/cc50AhRD.ltrans14.ltrans.o:<artificial>:function Test::Parser::Binary(): error: undefined reference to 'YAML::operator>>(YAML::Node const&, YAML::Binary&)'
/tmp/cc50AhRD.ltrans28.ltrans.o:<artificial>:function YAML::Emitter& YAML::Emitter::WriteIntegralType<int>(int): error: undefined reference to 'YAML::Emitter::PreWriteIntegralType(std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >&)'
/tmp/cc50AhRD.ltrans28.ltrans.o:<artificial>:function YAML::Emitter& YAML::Emitter::WriteIntegralType<int>(int): error: undefined reference to 'YAML::Emitter::PostWriteIntegralType(std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
test/CMakeFiles/run-tests.dir/build.make:211: recipe for target 'test/run-tests' failed
make[5]: *** [test/run-tests] Error 1
CMakeFiles/Makefile2:172: recipe for target 'test/CMakeFiles/run-tests.dir/all' failed
make[4]: *** [test/CMakeFiles/run-tests.dir/all] Error 2
Makefile:126: recipe for target 'all' failed
make[3]: *** [all] Error 2
external/CMakeFiles/YamlCppStaticLib.dir/build.make:111: recipe for target 'ThirdParty/Stamp/YamlCppStaticLib/YamlCppStaticLib-build' failed
make[2]: *** [ThirdParty/Stamp/YamlCppStaticLib/YamlCppStaticLib-build] Error 2
CMakeFiles/Makefile2:227: recipe for target 'external/CMakeFiles/YamlCppStaticLib.dir/all' failed
make[1]: *** [external/CMakeFiles/YamlCppStaticLib.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

...

[vitaly-krugl]

@pettitda, could you lend a hand? Pls see @codedhard's question in prior comment here. Thx!

[pettitda]

My solution was to switch from the original recipe to the recipe that @codedhard is using (listed at the top). I did start with a fresh install of Ubuntu 14.04.4LTS, so perhaps there is some change from 14.04LTS to 14.04.4LTS which is the key to fixing the problem. Actually, I tried both 14.04LTS and 16.04LTS before achieving success with 14.04.4LTS.

I actually intend to do exactly what @codedhard is trying to do, i.e. compile for the Raspberry Pi. I just set up the Raspberry Pi yesterday, so I will start working on it some time today. I will let you know if I have the same issue.

@codedhard, what OS are you using? Raspbian? Or something else? What revision of hardware are you using?

[vitaly-krugl]

@pettitda, please keep us all posted here. It would be great if you guys could collaborate on the solution. Thank you.

[codedhard]

@pettitda I have Raspberry Pi 3 Model B. Ubuntu Server Standard 15, image used downloaded from https://ubuntu-pi-flavour-maker.org/download/ . Now it is updated to 16.04 version. Unfortunately it's 32bit. Tools used: Win32DiskImager - image burning, putty - cmd over the network or a monitor + keyboard. My current CommonCompilerConfig.cmake - https://github.com/codedhard/nupic.core/blob/master/CommonCompilerConfig.cmake

Now I'm doing a complete fresh install.

Update. Same error.

[vitaly-krugl]

@codedhard and @pettitda: I opened issue #960 to make processor architecture-specific compiler/linker options conditional in nupic.core's cmake build system. Would you mind adding comments in #960, enumerating all of the options that you encountered that were incompatible with your ARM builds?

I started off with these two:

gcc: error: unrecognized argument in option '-mtune=generic'
gcc: error: unrecognized command line option '-m32'

and would like to get a complete list of them, in case there are more.

[pettitda]

I'm getting the same error here too. The build fails while linking run-tests.

[pettitda]

@vitaly-krugl : I'm getting a bunch of warnings before the build fails

BFD: ... : plugin needed to handle lto object

Is this normal?

[vitaly-krugl]

I am guessing you will want to start by removing the various compiler and linker optimization options in https://github.com/numenta/nupic.core/blob/master/CommonCompilerConfig.cmake to increase your chances for a successful ARM build. Just makes it as simple as possible. Once you get to a successful build, then see what makes sense to add back in for ARM.

[codedhard]

Got some progress. This error is related to nupic.core source code.

https://github.com/numenta/nupic.core/blob/master/src/nupic/math/ArrayAlgo.hpp " Algorithms on arrays, dense or sparse. Contains speed-optimized asm code that uses SIMD instructions provided by SSE in x86, only for darwin86 so far."

Building CXX object src/CMakeFiles/nupic_core_solo.dir/nupic/algorithms/Cell.cpp.o
In file included from /home/ubuntu/nupic.core/src/nupic/algorithms/Segment.hpp:34:0,
                 from /home/ubuntu/nupic.core/src/nupic/algorithms/Cell.hpp:28,
                 from /home/ubuntu/nupic.core/src/nupic/algorithms/Cell.cpp:23:
/home/ubuntu/nupic.core/src/nupic/math/ArrayAlgo.hpp: In function '(static initializers for /home/ubuntu/nupic.core/src/nupic/algorithms/Cell.cpp)':
/home/ubuntu/nupic.core/src/nupic/math/ArrayAlgo.hpp:97:29: error: impossible constraint in 'asm'
                            );
                             ^
src/CMakeFiles/nupic_core_solo.dir/build.make:704: recipe for target 'src/CMakeFiles/nupic_core_solo.dir/nupic/algorithms/Cell.cpp.o' failed
make[2]: *** [src/CMakeFiles/nupic_core_solo.dir/nupic/algorithms/Cell.cpp.o] Error 1
CMakeFiles/Makefile2:736: recipe for target 'src/CMakeFiles/nupic_core_solo.dir/all' failed
make[1]: *** [src/CMakeFiles/nupic_core_solo.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2

[pettitda]

I'm getting a different error here:

In file included from /usr/include/sched.h:28:0,
                 from /usr/include/pthread.h:23,
                 from /usr/include/arm-linux-gnueabihf/c++/4.9/bits/gthr-default.h:35,
                 from /usr/include/arm-linux-gnueabihf/c++/4.9/bits/gthr.h:148,
                 from /usr/include/c++/4.9/ext/atomicity.h:35,
                 from /usr/include/c++/4.9/bits/basic_string.h:39,
                 from /usr/include/c++/4.9/string:52,
                 from /usr/include/c++/4.9/stdexcept:39,
                 from /home/pi/nupic.core/src/nupic/types/Exception.hpp:31,
                 from /home/pi/nupic.core/src/nupic/utils/LoggingException.hpp:30,
                 from /home/pi/nupic.core/src/nupic/utils/Log.hpp:31,
                 from /home/pi/nupic.core/src/nupic/py_support/PyHelpers.hpp:34,
                 from /home/pi/nupic.core/src/nupic/py_support/PyArray.hpp:39,
                 from /home/pi/nupic.core/src/nupic/py_support/PyArray.cpp:30:
/home/pi/nupic.core/src/nupic/py_support/PyArray.cpp: In function ‘void nupic::initNumpy()’:
/home/pi/nupic.core/src/nupic/py_support/PyArray.cpp:67:5: error: return-statement with a value, in function returning 'void' [-fpermissive]
     import_array();
     ^
src/CMakeFiles/nupic_core_solo.dir/build.make:512: recipe for target 'src/CMakeFiles/nupic_core_solo.dir/nupic/py_support/PyArray.cpp.o' failed
make[2]: *** [src/CMakeFiles/nupic_core_solo.dir/nupic/py_support/PyArray.cpp.o] Error 1
CMakeFiles/Makefile2:736: recipe for target 'src/CMakeFiles/nupic_core_solo.dir/all' failed
make[1]: *** [src/CMakeFiles/nupic_core_solo.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2

Here's the changes I made to remove the optimizations:

diff --git a/CommonCompilerConfig.cmake b/CommonCompilerConfig.cmake
index 2bd049e..c6f2741 100644
--- a/CommonCompilerConfig.cmake
+++ b/CommonCompilerConfig.cmake
@@ -159,16 +159,16 @@ endif()
 # try compiling without them.
 #
 if(NOT ${CMAKE_CXX_COMPILER_ID} STREQUAL "MSVC")
-  set(optimization_flags_cc "${optimization_flags_cc} -mtune=generic -O2")
+  set(optimization_flags_cc "${optimization_flags_cc} -mtune=cortex-a7")
   set(optimization_flags_cc "-pipe ${optimization_flags_cc}") #TODO use -Ofast instead of -O3
-  set(optimization_flags_lt "-O2 ${optimization_flags_lt}")
+  set(optimization_flags_lt "${optimization_flags_lt}")

   if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" AND NOT MINGW)
     set(optimization_flags_cc "${optimization_flags_cc} -fuse-ld=gold")
     # NOTE -flto must go together in both cc and ld flags; also, it's presently incompatible
     # with the -g option in at least some GNU compilers (saw in `man gcc` on Ubuntu)
-    set(optimization_flags_cc "${optimization_flags_cc} -fuse-linker-plugin -flto-report -flto") #TODO fix LTO for clang
-    set(optimization_flags_lt "${optimization_flags_lt} -flto") #TODO LTO for clang too
+    set(optimization_flags_cc "${optimization_flags_cc}") #TODO fix LTO for clang
+    set(optimization_flags_lt "${optimization_flags_lt}") #TODO LTO for clang too
   endif()
 endif()

@@ -197,7 +197,7 @@ else()
   # LLVM Clang / Gnu GCC
   set(cxx_flags_unoptimized "${cxx_flags_unoptimized} ${stdlib_cxx} -std=c++11")

-  set(shared_compile_flags "${shared_compile_flags} -m${BITNESS} ${stdlib_common} -fdiagnostics-show-option")
+  set(shared_compile_flags "${shared_compile_flags} ${stdlib_common} -fdiagnostics-show-option")
   set (internal_compiler_warning_flags "${internal_compiler_warning_flags} -Werror -Wextra -Wreturn-type -Wunused -Wno-unused-variable -Wno-unused-parameter -Wno-missing-field-initializers")
   set (external_compiler_warning_flags "${external_compiler_warning_flags} -Wno-unused-variable -Wno-unused-parameter -Wno-incompatible-pointer-types -Wno-deprecated-declarations")

@@ -210,7 +210,7 @@ else()
     endif()
   endif()

-  set(shared_linker_flags_unoptimized "${shared_linker_flags_unoptimized} -m${BITNESS} ${stdlib_common} ${stdlib_cxx}")
+  set(shared_linker_flags_unoptimized "${shared_linker_flags_unoptimized} ${stdlib_common} ${stdlib_cxx}")
 endif()

Should the mtune be cortex-a53 instead of cortex-a7/8 for the BCM2837???

[rcrowder]

@pettitda It feels like a new CMake variable is required, similar to and alongside the use of PLATFORM_SUFFIX. A new variable could then used for the the tune parameter along with the use of the PLATFORM_SUFFIX. https://github.com/rcrowder/nupic.core/blob/master/CMakeLists.txt#L63

[pettitda]

I found an interesting discussion on the import_array() error:

https://mail.scipy.org/pipermail/numpy-discussion/2010-December/054357.html

[rcrowder]

@pettitda That discussion looks related to a difference between Python versions 2 and 3. Are you sure that your default Python installation is version 2, and the appropriate Python.his being picked up by the build?

[pettitda]

@rcrowder Yes, cmake was picking up the python include directory for Python 3.4. I went ahead and removed those libraries and the error went away. Now, I'm at the same point as @codedhard listed above with an error on ArrayAlgo.hpp.

[codedhard]

@pettitda That is good. I had changed this file https://github.com/codedhard/nupic.core/blob/master/ArrayAlgo.hpp . Put it in \src\nupic\math\ArrayAlgo.hpp .

[rcrowder]

@pettitda Excellent! I got the same point as you both when trying this on a 32-bit AWS EC2 instance a few months back. This was before Vitaly and Scott's changes to CMake to install external dependencies from source. @codedhard There should be a way with the NTA_ASM for working around any issues faced with GCC and inline assembler syntax. Undefining NTA_ASM will produce slow parts of nupic.core algorithms, but can be a way to progress before finding what the correct syntax for inline asm should be.

[rhyolight]

I'm out of my league here, but just want to say that I love that you folks are working on this. Thank you so much for helping.

[pettitda]

@codedhard it looks like you just inverted the logic of NTA_ASM. You should probably remove the '-DNTA_ASM' flag from the compiler definitions in nupic.core/src/CMakeLists.txt instead.

[pettitda]

I removed the -DNTA_ASM flag from nupic.core/src/CMakeLists.txt but there seems to be another place where its defined. Now I'm getting the error:

[ 74%] Building CXX object src/CMakeFiles/_math.dir/mathPYTHON_wrap.cxx.o
In file included from /home/pi/nupic.core/build/scripts/src/mathPYTHON_wrap.cxx:3183:0:
/home/pi/nupic.core/src/nupic/math/ArrayAlgo.hpp: In function ‘void nupic::logical_and(InputIterator, InputIterator, InputIterator, InputIterator, OutputIterator, OutputIterator) [with InputIterator = float*; OutputIterator = float*]’:
/home/pi/nupic.core/src/nupic/math/ArrayAlgo.hpp:5026:23: error: impossible constraint in ‘asm’
                      );
                       ^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-incompatible-pointer-types"
src/CMakeFiles/_math.dir/build.make:62: recipe for target 'src/CMakeFiles/_math.dir/mathPYTHON_wrap.cxx.o' failed
make[2]: *** [src/CMakeFiles/_math.dir/mathPYTHON_wrap.cxx.o] Error 1
CMakeFiles/Makefile2:486: recipe for target 'src/CMakeFiles/_math.dir/all' failed
make[1]: *** [src/CMakeFiles/_math.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2

[pettitda]

logical_and() and in_place_logical_and() have assembly code outside of the NTA_ASM switch.

[codedhard]

@pettitda . You need to delete the whole folder /build/scripts then create it again then cmake ... I had downgraded gcc to 4.9 the one that was installed was giving too many errors.

sudo apt-get install gcc-4.9 g++-4.9
cd /usr/bin
sudo rm gcc g++
sudo ln -s gcc-4.9 gcc
sudo ln -s g++-4.9 g++

My current errors is

    _math = swig_import_helper()
../.local/lib/python2.7/site-packages/nupic.bindings-0.4.3.dev0-py2.7-linux-armv7l.egg/nupic/bindings/math.py:24: in swig_import_helper
    _mod = imp.load_module('_math', fp, pathname, description)
E   ImportError: dynamic module does not define init function (init_math)

When I was doing "sudo make -j3", I got

c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
src/CMakeFiles/_math.dir/build.make:63: recipe for target 'src/CMakeFiles/_math.dir/mathPYTHON_wrap.cxx.o' failed
make[2]: *** [src/CMakeFiles/_math.dir/mathPYTHON_wrap.cxx.o] Error 4
make[2]: *** Waiting for unfinished jobs....
[100%] Building CXX object src/CMakeFiles/_math.dir/nupic/bindings/PySparseTensor.cpp.o
CMakeFiles/Makefile2:486: recipe for target 'src/CMakeFiles/_math.dir/all' failed

This is most likely because of "out of memory". This means I have to re-run whole installation with "make -j1" or somehow to increase memory.

[pettitda]

I got nupic.core to completely compile and pass the tests today. I had to make the following changes to ArrayAlgo.hpp:

    // See comments in count_gt. We need both conditional compilation and 
     // SSE_LEVEL check.
-#if !defined(NTA_OS_WINDOWS)
+#if !defined(NTA_OS_WINDOWS) && defined(NTA_ASM)

     if (SSE_LEVEL >= 3) {

@@ -5099,7 +5099,7 @@ namespace nupic {

     // See comments in count_gt. We need conditional compilation
     // _AND_ SSE_LEVEL check.
-#if defined(NTA_OS_LINUX) || defined(NTA_OS_DARWIN)
+#if (defined(NTA_OS_LINUX) || defined(NTA_OS_DARWIN)) && defined(NTA_ASM)

     if (SSE_LEVEL >= 3) {

When I go to the setup step for Nupic, I get the following error:

Processing dependencies for nupic==0.5.3.dev0
Searching for nupic.bindings==0.4.3.dev0
Reading https://pypi.python.org/simple/nupic.bindings/
No local packages or download links found for nupic.bindings==0.4.3.dev0
error: Could not find suitable distribution for Requirement.parse('nupic.bindings==0.4.3.dev0')

[rcrowder]

@pettitda Good job on getting core to compile and link. Did you run the python setup.py process in nupic.core to build the core python bindings, before trying nupic setup.py?

[pettitda]

Yes, I did. I used this sequence of commands:

make install
cd $NUPIC_CORE/build/release/bin
./cpp_region_test
./unit_tests
cd $NUPIC_CORE
python setup.py install --user
cd $NUPIC
python setup.py install --user

I started running the commands as root, but after running the unit_tests I realized that I was supposed to run as user. So, I went back and removed the release directory and started over. I then ran into some issues with the install script having changed permissions on some of the files in the source directories. However, I manually changed them one by one back to user group and owner.

[pettitda]

Looks like the file is there:

pi@raspberrypi:~/nupic $ ls /home/pi/.local/lib/python2.7/site-packages/
apipkg-1.4.dist-info       numpy-1.9.2.dist-info
apipkg.py                  nupic-0.5.3.dev0-py2.7.egg
apipkg.pyc                 nupic.bindings-0.4.4.dev0-py2.7-linux-armv7l.egg
capnp                      py
cov_core-1.15.0.dist-info  py-1.4.31.dist-info
cov_core_init.py           pycapnp-0.5.7.dist-info
cov_core_init.pyc          _pytest
cov_core.py                pytest-2.5.1.dist-info
cov_core.pyc               pytest_cov-1.6.dist-info
coverage                   pytest_cov.py
coverage-4.0.3.dist-info   pytest_cov.pyc
easy-install.pth           pytest.py
execnet                    pytest.pyc
execnet-1.4.1.dist-info    pytest_xdist-1.8.dist-info
numpy                      xdist
pi@raspberrypi:~/nupic $

[rcrowder]

I wonder if this is the dreaded pip and setuptools changes to egg file names introduced earlier this year. What version of pip and setuptools do you have on the Pi?

[rcrowder]

Oh wait. That shows 0.4.4 whereas nupic requirements was looking for 0.4.3 Maybe your nupic and nupic.core forks are out of sync. You could trying changing nupic requirements.txt locally to force it to look for 0.4.4

[pettitda]

pi@raspberrypi:~/nupic $ apt show python-setuptools
Package: python-setuptools
Version: 5.5.1-1
Installed-Size: 770 kB
Maintainer: Matthias Klose <doko@debian.org>
Replaces: python-distribute (<< 0.6.6)
Provides: python-distribute, python2.7-setuptools
Depends: python:any (>= 2.7), python:any (<< 2.8), python-pkg-resources (= 5.5.1-1)
Conflicts: python-distribute (<< 0.7)
Download-Size: 242 kB
Homepage: https://pypi.python.org/pypi/setuptools
Python-Version: 2.7
Tag: devel::lang:python, implemented-in::python, interface::commandline,
 role::plugin, use::configuring
Section: python
Priority: optional
APT-Manual-Installed: no
APT-Sources: http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
Description: Python Distutils Enhancements
 Extensions to the python-distutils for large or complex distributions.

pi@raspberrypi:~/nupic $ pip --version
pip 8.1.2 from /usr/local/lib/python2.7/dist-packages (python 2.7)

[rcrowder]

(Info for others reading this covo.) I should state that it is not advisable to change nupic requirements to force it to find a different nupic.core version. Both nupic and nupic.core must be in lock-step when building from source or installing pre-built versions.

[pettitda]

That worked. I'm running run_nupic_tests.py now.

Do I need to clean the nupic directory before I pull the latest version?

[rcrowder]

If you nupic is a fork you'll need to merge into the fork before a pull. If it is a clone of master then no, you can just pull the master and git should handle the merge and show any potential conflicts with local edits.

[pettitda]

Okay, I'll update my nupic clone and re-run.

run_nupic_tests.py ended with:

E         AssertionError: Key _inputDimensions has differing dtypes: int32 vs int64

tests/unit/nupic/research/spatial_pooler_unit_test.py:1754: AssertionError
------------------------------- Captured stdout --------------------------------
New seed generated as: 15940 called by run line 320 -> setUp
============= 10 failed, 856 passed, 24 skipped in 1004.57 seconds =============

[rhyolight]

@codedhard @pettitda @rcrowder Just catching up on this issue. Great work, all! Feel free to use gitter to chat in real time if it helps.

[pettitda]

I got everything to compile on the Raspberry Pi 3 using Raspbian. Now I'm diving into how to use nupic.

[rcrowder]

@pettitda I got a Raspberry Pi3 delivered this week. Let me know if I can help get a PR together with the required initial changes.

[pettitda]

Look at what I have here: https://github.com/pettitda/nupic.core.git

I didn't get around to adding the switch around the changes in CommonCompilerConfig.cmake.

[pettitda]

If you can give me some guidelines on style, I can probably find time to get it into shape for a PR. I just haven't looked at/for the requirements for this project.

[rcrowder]

One obvious thing that could change before a PR, is the handling of the GCC flags. The cmake CheckCXXCompilerFlag module can be used to check the handling of options such as the -m flag. Optimizations, including LTO, will need to be tidied up. I'll pull your changes onto the Pi3, tomorrow?, and have a look at making a PR onto your changes to help towards you making a final PR onto master.

[rcrowder]

I made progress today with pettitda's repo and some local changes to tidy up the GCC flags. Got as far as having the nupic.core unit tests all running and passing on the Raspberry Pi3. I hit memory problems when trying to get the math Python bindings built. So will need to look into that further (possibly external HDD used as a swap partition, or split/simplify down the math binding compile size).

[rcrowder]

@pettitda Here's a comparison of the changes accumulated so far - https://github.com/numenta/nupic.core/compare/master...rcrowder:pi3-changes Maybe you can adopt some of these changes into your clone, to be able to make a PR against master?

[rcrowder]

For future reference; On certain Raspberry PI Linux distros, memory usage during the building of nupic.bindings can become an issue (particularly mathPYTHON_wrap.cxx). A swap partition (or temporary swapfile) is therefore required during the make processing.