@fgervais Did you ever manage to build raspberry pi wheel for python 3.7? I am seeing the same behavior, builds for PI-PYTHON3 but not for PI-PYTHON37. I just booted up Ubuntu 19.10 armhf on my Raspberry Pi 4 device (which has python3.7 installed) and was hoping to give this a spin (I tried the arm64/aarch64 image as well, see below if you're interested).

@petewarden Do you have any recommendations for getting TensorFlow running on RPI4? I noticed the Build from source for the Raspberry Pi instructions only cover armhf and not aarch64, kind of like Build TensorFlow Lite for Raspberry Pi covers RPI4 but only in the context of armhf (haven't tried this one just yet). I saw and tried the Build TensorFlow Lite for ARM64 boards instructions, but was unsuccessful at the time (sorry, I don't have the exact error at this moment). Anyways, any tips would be greatly appreciated.

@settle I couldn't make it work, I changed my plan and built a docker image based on debian:stretch (which uses python 3.5) and added then tensorflow dependencies on top.

See here:

#36672 (comment)

@fgervais Did you build a devel docker image that can build tensorflow inside it, or you just installed a tensorflow binary inside the docker image? If the former, could you share you Dockerfile? I've attempted to do that myself, but run into issues building bazel, see #37985.

Btw, what would be your opinion of doing pip install vs. apt-get for the python packages in my Dockerfile. I ask because it's extremely slow to compile the python dependencies (specifically matplotlib and scipy) when using pip install and would be much faster installing the pre-built python packages and all their dependencies using apt-get. Some of the messages during pip install make me worried I still don't have all the dependencies.

@settle I installed the tensorflow binary inside a docker image.

I prefer to pip to install the dependencies to I get more control on the versions installed. It is slow, yes, but not too bad since I do it through docker buildx. Even if it's through emulation, it's still a lot faster than on a raspberry pi.

@fgervais, you need to update CROSSTOOL_PYTHON_INCLUDE_PATH to point Python 3.7 header files.
Please use "CROSSTOOL_PYTHON_INCLUDE_PATH=/usr/include/python3.7" at your CI_DOCKER_EXTRA_PARAMS.

@fgervais, you need to update CROSSTOOL_PYTHON_INCLUDE_PATH to point Python 3.7 header files.
Please use "CROSSTOOL_PYTHON_INCLUDE_PATH=/usr/include/python3.7" at your CI_DOCKER_EXTRA_PARAMS.

@terryheo I tried this today on r2.2 branch, but keep running into build errors related to memory consumption, see below. I don't know why since my build machine has 128 GB of RAM and I never see it coming near the limit in docker stats.

ERROR: /workspace/tensorflow/compiler/mlir/lite/BUILD:547:1: C++ compilation of rule '//tensorflow/compiler/mlir/lite:flatbuffer_translate_lib' failed (Exit 1)
virtual memory exhausted: Cannot allocate memory

@terryheo I've been rerunning the build script above to see if I can glean any more information and this time the error was more helpful, see below. Question is, how to increase the JRE memory size to this docker cross compilation build script flow? Or any other fix?

ERROR: /workspace/tensorflow/core/kernels/BUILD:4101:1: C++ compilation of rule '//tensorflow/core/kernels:reduction_ops' failed (Exit 1)

cc1plus: out of memory allocating 20521 bytes after a total of 1003520 bytes
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f66960a2000, 262144, 0) failed; error='Not enough space' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 262144 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /workspace/hs_err_pid92913.log

@settle interesting. I think you might want to check https://docs.bazel.build/versions/master/memory-saving-mode.html
But you said that you have 128GB ram, it should be OK.

Just wondering, what's the output of following commands?

$ docker --version
$ docker run tf_ci.pi-python37 cat /proc/meminfo

@terryheo I'm only familiar to using --local_ram_resources=2048 when building with bazel following the Build from source instructions. How exactly would I pass those memory saving mode like --host_jvm_args=-Xmx2g to this cross compilation flow?

$ docker --version
Docker version 19.03.2, build 6a30dfc

$ docker run tf_ci.pi-python37 cat /proc/meminfo
MemTotal: 97398140 kB
MemFree: 84689100 kB
MemAvailable: 94768644 kB
Buffers: 2086196 kB
Cached: 7819040 kB
SwapCached: 1592 kB
Active: 4651344 kB
Inactive: 5841044 kB
Active(anon): 324812 kB
Inactive(anon): 262192 kB
Active(file): 4326532 kB
Inactive(file): 5578852 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 1998844 kB
SwapFree: 1991408 kB
Dirty: 304 kB
Writeback: 0 kB
AnonPages: 579348 kB
Mapped: 346624 kB
Shmem: 19472 kB
Slab: 1731056 kB
SReclaimable: 1028488 kB
SUnreclaim: 702568 kB
KernelStack: 22176 kB
PageTables: 20692 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 89657168 kB
Committed_AS: 4151700 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 1417216 kB
DirectMap2M: 65132544 kB
DirectMap1G: 34603008 kB

You can have custom Bazel option with .bazelrc.user file.
Before using it, could you increase your swap? Your SwapTotal is only 2G. Could you try with higher number?

@terryheo Just to confirm and for reference, you mean try adding something like --memory=96g --memory-swap=4g to the docker run line in tensorflow/tools/ci_build/ci_build.sh? I just gave that a try, but noticed the following line printed so doesn't appear to have worked:

"WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap."

@terryheo Quick follow up, indeed the build continued to fail as before. After some searching I found how to modify my kernel with grub to allow the swap limit, see How to limit a docker container’s resources on ubuntu 18.04. After that I was able to successfully cross-compile build a whl, but it still shows the wrong python version, i.e., tensorflow-2.2.0-cp35-none-linux_armv7l.whl. Am I still doing something wrong?

CI_DOCKER_EXTRA_PARAMS="-e CI_BUILD_PYTHON=python3 -e CROSSTOOL_PYTHON_INCLUDE_PATH=/usr/include/python3.7" tensorflow/tools/ci_build/ci_build.sh PI-PYTHON37 tensorflow/tools/ci_build/pi/build_raspberry_pi.sh

If I try to change the CI_BUILD_PYTHON=python3 above to CI_BUILD_PYTHON=python3.7 then I get this error that didn't appear when I built the above whl file:

ImportError: cannot import name 'multiarray' from 'numpy.core' (/usr/lib/python3/dist-packages/numpy/core/init.py)
Is numpy installed?

@settle Hello,

I would like to build a wheel file for my Raspberry Pi 3B (Buster) with TensorFlow version 2.3.0rc0.
So I run the following command :
CI_DOCKER_EXTRA_PARAMS="-e CI_BUILD_PYTHON=python3 -e CROSSTOOL_PYTHON_INCLUDE_PATH=/usr/include/python3.7" tensorflow/tools/ci_build/ci_build.sh PI-PYTHON37 tensorflow/tools/ci_build/pi/build_raspberry_pi.sh

However, the output I obtain is the wheel file for Python 3.5 like you... (tensorflow-2.3.0rc0-cp35-none-linux_armv7l.whl)
Did you manage to make it work?

I've also verified PI-PYTHON37 container doesn't work as expected.
I've investigated a bit and it's not simple to fix.

Please use Python 3.5 interpreter instead.

I've found a solution. Let me prepare PR.

PR is merged. You can build RPI3 PIP wheel for Python 3.7 as following.

CI_DOCKER_EXTRA_PARAMS="-e CI_BUILD_PYTHON=python3.7 -e CROSSTOOL_PYTHON_INCLUDE_PATH=/usr/include/python3.7" \
  tensorflow/tools/ci_build/ci_build.sh PI-PYTHON37 \
  tensorflow/tools/ci_build/pi/build_raspberry_pi.sh

Are you satisfied with the resolution of your issue?
Yes
No