Google's Bazel When Run In Gentoo: STD C++ headers not found

[jlpoole]

I am trying to compile the USB library, libedgetpu supporting Google's USB Coral board (suggested price of $59.99) so I can perform edge detection recognizing, for example, cars, trucks and buses) in surveillance videos. An example of a video (35 MBs) I shot of Interstate 5 highway at Salem, Oregon, is at: https://salemdata.us/videos/I5_D_Street_Convert2MP4.mp4, this video with detections was not performed with a Coral board, but processed using Google's "notebook". I should note that I did install a Jupyter notebook system on a VM atop an AMD Bulldozer (2013) processor and what took 8-12 minutes on Google's Jupyter with access to an Nvidia graphics accelerator, took 6 hours or more just using an AMD processor. Some other experiments with Google's Coral Dev kit have shown that the Google Coral accelerator reduces hours of processing down to seconds, so for $60 having a Google Coral board attached via USB could be a real game changer for video analysis.

The project uses the open source BAZEL build system which is a derivative of Google's proprietary build system BLAZE. Although the project documentation says that the library supporting the USB Coral component can be built without BAZEL, I'm finding that assertion is no longer true and the result is you run "make" which, in turn, calls Bazel. This particular project is quite complex. A nifty feature of the BAZEL system is that you can created an pictorial diagram of the dependencies, which I did for kicks, and you can view the PNG representation of the graphviz-generated SVG at: graph (27 MB)and graph_simplified (20 MB).

My first roadblock was that Bazel was not finding the C++ compiler. I overcame that by modifying my PATH variable to point to gcc's C++ compiler. See libedgetpu gcc: fatal error: cannot execute 'cc1plus' Hu noted in the topic that my output suggested the compiler was also not finding the standard C++ headers. Well, here I am and I've isolated that issue into this topic because it may be something that Bazel is configured in such a way that it cannot find the standard C++ headers on a Gentoo system.

For this build, I have debugging activated which was achieved by modifying the top level Makefile:

Code: Select all

jlpoole@eos ~/libedgetpu $ diff Makefile_ORIGINAL Makefile
68a69,71
> #
> # 11/20/2022 jlpoole: added "--sandbox_debug" after failed output suggested using same
> #
69a73
>   --sandbox_debug \
jlpoole@eos ~/libedgetpu $

The entire "make" log is at https://pastebin.com/CciGwVH2 (1 year life). The pertinent portion is this error message @191-104:

Code: Select all

bazel-out/host/bin/external/flatbuffers/src/_virtual_includes/flatc/flatbuffers/flatc.h:20:10: fatal error: functional: No such file or directory
   20 | #include <functional>
      |          ^~~~~~~~~~~~
compilation terminated.

I've been searching the Bazel manual to learn where standard C++ header locations might be defined, but have not found that... yet. Bazel documentation states that all headers, except for the default C++, must be defined. Well, I believe something in Gentoo's configuration is breaking an assumption the Bazel team is making about Linux systems. If my belief is true, then other Bazel builds for C++ on a Gentoo box may suffer the same problem. I have identified where the standard C++ headers are, but I have not yet found where I can plug in their location to force Bazel, in all the components, to find them.

Code: Select all

    jlpoole@eos ~/libedgetpu $ clang -E -xc++ - -v
    clang version 15.0.5
    Target: x86_64-pc-linux-gnu
    Thread model: posix
    InstalledDir: /usr/lib/llvm/15/bin
    Configuration file: /etc/clang/clang.cfg
    System configuration file directory: /etc/clang
    Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0
    Candidate multilib: .;@m64
    Candidate multilib: 32;@m32
    Selected multilib: .;@m64
     (in-process)
     "/usr/lib/llvm/15/bin/clang-15" -cc1 -triple x86_64-pc-linux-gnu -E -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/jlpoole/libedgetpu -resource-dir /usr/lib/llvm/15/bin/../../../../lib/clang/15.0.5 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/x86_64-pc-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/backward -internal-isystem /usr/lib/llvm/15/bin/../../../../lib/clang/15.0.5/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir=/home/jlpoole/libedgetpu -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o - -x c++ -
    clang -cc1 version 15.0.5 based upon LLVM 15.0.5 default target x86_64-pc-linux-gnu
    ignoring nonexistent directory "/usr/local/include"
    ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/include"
    ignoring nonexistent directory "/include"
    #include "..." search starts here:
    #include <...> search starts here:
     /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11
     /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/x86_64-pc-linux-gnu
     /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/backward
     /usr/lib/llvm/15/bin/../../../../lib/clang/15.0.5/include
     /usr/include
    End of search list.

    ^C
    jlpoole@eos ~/libedgetpu $

As an aside, I have Ubuntu on a VM and I plan to try and make the libedgetpu project on that VM to see if my belief that Bazel is making certain assumptions about locations as might be found on a Ubuntu system. Unfortunately, I'm gated now because my xen install hit a bug which I'll have to log after this so I can resurrect my hypervisor.

Anyone familiar with Bazel and C++ compilation and where one might add some of the above paths, i.e. /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11?

[jlpoole]

An update. Problem not solved, but progress is being made. There is a file in the probject .bazelrc. I modified the file as follows:

Code: Select all

common --experimental_repo_remote_exec

build --define darwinn_portable=1
build --subcommands
build --verbose_failures
build --enable_platform_specific_config

build:linux --crosstool_top=@crosstool//:toolchains
#
# 12/24/2022 jlpoole:  using compiler=gcc causes error message:
#   gcc: fatal error: cannot execute 'cc1plus': execvp: No such file or directory
#
#build:linux --compiler=gcc
#
# 12/24/2022 10:00 PST jlpoole: using compiler=g++ causes error message:
# ERROR: /home/jlpoole/.cache/bazel/_bazel_jlpoole/3933de89ff5fedd41a5a7d73a592148c/external/crosstool/BUILD:24:19: in cc_toolchain_suite rule @crosstool//:toolchains: cc_toolchain_suite '@crosstool//:toolchains' does not contain a toolchain for cpu 'k8' and compiler 'g++'.
#
build:linux --compiler=g++

build:macos --cxxopt=-std=c++14
build:macos --copt=-fvisibility=hidden

build:windows --incompatible_restrict_string_escapes=false
build:windows --copt=/DWIN32_LEAN_AND_MEAN
build:windows --cxxopt=/std:c++14

I worked through the tutorial (and log some issues against the documentation for very minor points) at https://bazel.build/tutorials/ccp-toolchain-config and finally got the simple sample to work. I took Google's stage1 sample and made a sibling directory stage1B for purposes of modifying in accordance with the tutorial. I achieved success with /home/jlpoole/tutorial/examples/cpp-tutorial/stage1B
specifying in cc_toolchain_confg.bzl g++ as the path for gcc:

Code: Select all

        tool_path(
            name = "gcc",
            #path = "/usr/bin/clang",
	    #path = "/usr/lib/llvm/15/bin/clang",
	    #path = "/usr/bin/gcc",
	    path = "/usr/bin/g++",
        ),

and:

Code: Select all

cxx_builtin_include_directories = [ # NEW
	#"/usr/lib/llvm-9/lib/clang/9.0.1/include",
	# failed: "/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/",
	# failed: "/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11",
	# failed: "/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/cstdlib",
	# failed: "/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/tr1",
	# failed: "/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/tr1/cstdlib",
	
	# failed: "/usr/include/boost/compatibility/cpp_c_headers/",
	# failed: "/usr/include/boost/compatibility/cpp_c_headers",
	# failed: "/usr/include/boost/compatibility/cpp_c_headers/cstdlib",

	"/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include",
	"/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11",
	#"/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/tr1",
	#"/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/cstdlib",
	#"/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/tr1/cstdlib",
        "/usr/include",
	#"/usr/include/linux",
      ],    

I'm sharing this progress in case some one, some day, decides they want to tackle a Google Bazel-based project in Gentoo. I'll update further as I hopefully make progress. It is my opinion that the Bazel system is excellent, but it just needs tweaking to adapt to a Gentoo environment. They even admit so in their documentation with "warning" about custom configuration settings. The trick, of course, is to ferret out just where these settings should be. The aforesaid tutorial takes the approach of: one error at a time and build upon fixing each error. The problem with that approach is that there should be an accompanying guide that gives the overall architecture explanation of where things are are should be in this bowl of spaghetti.

[jlpoole]

Success. I successfully built and compiled the project which produces the Coral USB libraries (basic and throttled): libedgetpu.so.1.0. Whether the library works or not remains to be determined; I'll be using the Python examples for testing.

Code: Select all

jlpoole@eos ~/libedgetpu $ find . -type f -name "libedge*"|xargs ls -la
-rw-r--r-- 1 jlpoole jlpoole      76 Nov 11 15:43 ./debian/libedgetpu-dev.install
-rw-r--r-- 1 jlpoole jlpoole     276 Nov 11 15:43 ./debian/libedgetpu1-max.lintian-overrides
-rw-r--r-- 1 jlpoole jlpoole     426 Nov 11 15:43 ./debian/libedgetpu1-max.preinst
-rw-r--r-- 1 jlpoole jlpoole    1186 Nov 11 15:43 ./debian/libedgetpu1-max.templates
-rw-r--r-- 1 jlpoole jlpoole      26 Nov 11 15:43 ./debian/libedgetpu1-max.triggers
-rw-r--r-- 1 jlpoole jlpoole     138 Nov 11 15:43 ./debian/libedgetpu1-std.lintian-overrides
-rw-r--r-- 1 jlpoole jlpoole      26 Nov 11 15:43 ./debian/libedgetpu1-std.triggers
-r-xr-xr-x 1 jlpoole jlpoole 1045000 Dec 24 13:43 ./out/direct/k8/libedgetpu.so.1.0
-r-xr-xr-x 1 jlpoole jlpoole 1049176 Dec 24 13:43 ./out/throttled/k8/libedgetpu.so.1.0
-rw-r--r-- 1 jlpoole jlpoole     976 Nov 11 15:43 ./tflite/public/libedgetpu.lds
jlpoole@eos ~/libedgetpu $

I have a lot of notes/comments strewn in the files I modified and added. I will try to winnow my comments down to essentials with explanations and post hereafter, probably within the next 3 days. Basically, I just had to create a custom override so that when Bazel calls gcc, it really is calling g++. Not that anyone is chomping at the bit to achieve compiling the Coral USB libraries, but I suppose some might be monitoring this as a novel exercise and I thought I'd share this development lest anyone put any time and thought into this for suggestions.

[jlpoole]

Success.

I confirmed the Coral board and the libedgetpu library work on my System 76 laptop. I have to run the python script as root.

Code: Select all

eos /home/jlpoole/coral/tflite/python/examples/classification #  date; time python3 classify_image.py --model models/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite --labels models/inat_bird_labels.txt --input images/parrot.jpg
Sat Dec 24 20:59:17 PST 2022
/home/jlpoole/coral/tflite/python/examples/classification/classify_image.py:103: DeprecationWarning: ANTIALIAS is deprecated and will be removed in Pillow 10 (2023-07-01). Use Resampling.LANCZOS instead.
  image = Image.open(args.input).convert('RGB').resize(size, Image.ANTIALIAS)
----INFERENCE TIME----
Note: The first inference on Edge TPU is slow because it includes loading the model into Edge TPU memory.
111.5ms
11.0ms
10.6ms
10.9ms
11.1ms
-------RESULTS--------
Ara macao (Scarlet Macaw): 0.77734

real	0m3.557s
user	0m0.197s
sys	0m0.022s
eos /home/jlpoole/coral/tflite/python/examples/classification # 

I had to install the module as user root, too.

Code: Select all

eos /home/jlpoole/tensorflow # ls tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/
tflite-runtime-2.10.1.linux-x86_64.tar.gz  tflite_runtime-2.10.1-cp310-cp310-linux_x86_64.whl
eos /home/jlpoole/tensorflow # python3 -m pip install --user tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/tflite_runtime-2.10.1-cp310-cp310-linux_x86_64.whl
Processing ./tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/tflite_runtime-2.10.1-cp310-cp310-linux_x86_64.whl
Requirement already satisfied: numpy>=1.19.2 in /usr/lib/python3.10/site-packages (from tflite-runtime==2.10.1) (1.23.4)
Installing collected packages: tflite-runtime
Successfully installed tflite-runtime-2.10.1
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
eos /home/jlpoole/tensorflow # 

I installed the module as user jlpoole, then if I try as a non-privileged user, I got this error:

Code: Select all

jlpoole@eos ~/coral/tflite/python/examples/classification $ date; time python3 classify_image.py --model models/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite --labels models/inat_bird_labels.txt --input images/parrot.jpg
Sat Dec 24 20:58:32 PST 2022
Traceback (most recent call last):
  File "/home/jlpoole/.local/lib/python3.10/site-packages/tflite_runtime/interpreter.py", line 174, in load_delegate
    delegate = Delegate(library, options)
  File "/home/jlpoole/.local/lib/python3.10/site-packages/tflite_runtime/interpreter.py", line 112, in __init__
    raise ValueError(capture.message)
ValueError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jlpoole/coral/tflite/python/examples/classification/classify_image.py", line 122, in <module>
    main()
  File "/home/jlpoole/coral/tflite/python/examples/classification/classify_image.py", line 99, in main
    interpreter = make_interpreter(args.model)
  File "/home/jlpoole/coral/tflite/python/examples/classification/classify_image.py", line 72, in make_interpreter
    tflite.load_delegate(EDGETPU_SHARED_LIB,
  File "/home/jlpoole/.local/lib/python3.10/site-packages/tflite_runtime/interpreter.py", line 176, in load_delegate
    raise ValueError('Failed to load delegate from {}\n{}'.format(
ValueError: Failed to load delegate from libedgetpu.so.1


real	0m25.266s
user	0m0.191s
sys	0m0.071s
jlpoole@eos ~/coral/tflite/python/examples/classification $

I'll have to diagnose what privileges are in play and what can be done about having a regular user access the Coral USB device from within Python.

[jlpoole]

I was able to successfully build libedgetpu on a Raspberry Pi 4B running GenPi64. The measure of success is simply the running of the two test scripts suggested in the following instructions.

The main instructions I used: https://coral.ai/docs/notes/build-coral/ as well as the project https://github.com/google-coral/libedgetpu

To build within Gentoo, we need some Google technology installed:

Code: Select all

 emerge dev-util/bazel  dev-libs/flatbuffers dev-cpp/abseil-cpp

To build on an AMD64

1) Stage Tensorflow and checkout latest stable version. You might referenced Tensorflow Release Tags: https://github.com/tensorflow/tensorflow/tags as you'll need to select a release and specify same for your build environment.

Code: Select all

git clone https://github.com/tensorflow/tensorflow.git
cd tensorflow
git checkout tags/v2.11.0
cd ..

2) Stage Libedgetpu

Code: Select all

 git clone https://github.com/google-coral/libedgetpu
cd libedgetpu

I found adding a debug statement as a default helpful, so I modified Makefile as suggested:

Code: Select all

jlpoole@eos ~/libedgetpu $ diff Makefile_ORIGINAL Makefile
68a69,71
> #
> # 11/20/2022 jlpoole: added "--sandbox_debug" after failed output suggested using same
> #
69a73
>   --sandbox_debug \
jlpoole@eos ~/libedgetpu $

To overcome the problem described in an earlier posting in this topic of running Bazel within Gentoo Linux, I did the following. But I hasten to mention how helpful it was to have this Bazel resource in helping me understand the pointer system within Bazel that invokes gcc: https://bazel.build/tutorials/ccp-toolchain-config

A) modified .bazelrc:

Code: Select all

jlpoole@eos ~/libedgetpu $ git --no-pager diff .bazelrc
diff --git a/.bazelrc b/.bazelrc
index 49d2bb8..428c602 100644
--- a/.bazelrc
+++ b/.bazelrc
@@ -1,3 +1,5 @@
+
+
 common --experimental_repo_remote_exec

 build --define darwinn_portable=1
@@ -5,8 +7,25 @@ build --subcommands
 build --verbose_failures
 build --enable_platform_specific_config

-build:linux --crosstool_top=@crosstool//:toolchains
-build:linux --compiler=gcc
+#build:linux --crosstool_top=@crosstool//:toolchains
+#
+# 12/24/2022 jlpoole:  using compiler=gcc causes error message:
+#   gcc: fatal error: cannot execute 'cc1plus': execvp: No such file or directory
+#
+#build:linux --compiler=gcc
+#
+# 12/24/2022 10:00 PST jlpoole: using compiler=g++ causes error message:
+# ERROR: /home/jlpoole/.cache/bazel/_bazel_jlpoole/3933de89ff5fedd41a5a7d73a592148c/external/crosstool/BUILD:24:19: in cc_toolchain_suite rule @crosstool//:toolchains: cc_toolchain_suite '@crosstool//:toolchains' does not contain a toolchain for cpu 'k8' and compiler 'g++'.
+#
+#build:linux --compiler=g++
+#build:linux --compiler=gcc
+
+#
+# 12/24/2022 10:00 PST jlpoole: added "cxxopt=-std=c++11"
+#                    since our compiler is v11 and Google's mac settings seems to suggest
+#                               that v14 is specified, so we want to know of any incompatabilities at the outset
+#
+build:linux --cxxopt=-std=c++11

 build:macos --cxxopt=-std=c++14
 build:macos --copt=-fvisibility=hidden
@@ -14,3 +33,31 @@ build:macos --copt=-fvisibility=hidden
 build:windows --incompatible_restrict_string_escapes=false
 build:windows --copt=/DWIN32_LEAN_AND_MEAN
 build:windows --cxxopt=/std:c++14
+#
+# 12/24/22 10:34 PST jlpoole: Below are additions of jlpoole based on tutorial at:
+#   https://bazel.build/tutorials/ccp-toolchain-config
+#  Note: it does not seem to affect the error output as to whether the lines below are at the
+#  end of this file or at the beginning, so I'm leaving them here at the beginning
+#
+
+#
+# -------------- START of Google Tutorial additions -----------------
+#
+
+# Use our custom-configured c++ toolchain.
+
+build:clang_config --crosstool_top=//toolchain:clang_suite
+#build:linux --crosstool_top=//toolchain:clang_suite
+
+# Use --cpu as a differentiator.
+
+build:clang_config --cpu=k8
+
+# Use the default Bazel C++ toolchain to build the tools used during the
+# build.
+
+build:clang_config --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
+
+#
+# -------------- END of Google Tutorial additions -----------------
+#
\ No newline at end of file
jlpoole@eos ~/libedgetpu $

B) Added directory "toolchain" and files therein:

Code: Select all

jlpoole@eos ~/libedgetpu $ cat toolchain/BUILD
package(default_visibility = ["//visibility:public"])

load(":cc_toolchain_config.bzl", "cc_toolchain_config")


#filegroup(name = "clang_suite")  # replaced by following lines
cc_toolchain_suite(
    name = "clang_suite",
    toolchains = {
        #"k8": ":k8_toolchain",
    },
)

filegroup(name = "empty")

cc_toolchain(
    name = "k8_toolchain",
    toolchain_identifier = "k8-toolchain",
    toolchain_config = ":k8_toolchain_config",
    all_files = ":empty",
    compiler_files = ":empty",
    dwp_files = ":empty",
    linker_files = ":empty",
    objcopy_files = ":empty",
    strip_files = ":empty",
    supports_param_files = 0,
)
#filegroup(name = "k8_toolchain_config")
cc_toolchain_config(name = "k8_toolchain_config")

jlpoole@eos ~/libedgetpu $ cat toolchain/cc_toolchain_config.bzl

load("@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl", "tool_path")

def _impl(ctx):
    tool_paths = [ # NEW
        tool_path(
            name = "gcc",
            #name = "g++",
            #path = "/usr/bin/clang",
            path = "/usr/bin/g++",
        ),
        tool_path(
            name = "ld",
            path = "/usr/bin/ld",
        ),
        tool_path(
            name = "ar",
            path = "/usr/bin/ar",
        ),
        tool_path(
            name = "cpp",
            path = "/bin/false",
        ),
        tool_path(
            name = "gcov",
            path = "/bin/false",
        ),
        tool_path(
            name = "nm",
            path = "/bin/false",
        ),
        tool_path(
            name = "objdump",
            path = "/bin/false",
        ),
        tool_path(
            name = "strip",
            path = "/bin/false",
        ),
    ]
    return cc_common.create_cc_toolchain_config_info(
        ctx = ctx,
        toolchain_identifier = "local",
        host_system_name = "local",
        target_system_name = "local",
        target_cpu = "k8",
        target_libc = "unknown",
        #compiler = "clang",
        #compiler = "g++",
        compiler = "gcc",
        abi_version = "unknown",
        abi_libc_version = "unknown",
        tool_paths = tool_paths, # NEW
    )


cc_toolchain_config = rule(
    implementation = _impl,
    attrs = {},
    provides = [CcToolchainConfigInfo],
)
jlpoole@eos ~/libedgetpu $

I then ran:

Code: Select all

date; time make

At some point during the build, there was a failure and a suggested fix:

Code: Select all

bazel-out/host/bin/external/flatbuffers/src/_virtual_includes/flatc_library/flatbuffers/flatc.h:20:10: fatal error: functional: No such file or directory
       20 | #include <functional>
          |          ^~~~~~~~~~~~
    compilation terminated.

That was easily fixed by performing the inserting of the single line. I came across this a couple of times both in the AMD build and the ARM64 build. You need to be careful about where in the file you stick the include statement, I opted to place it before and "IF" statements to assure it was run.

After building the library, I placed the throttled version (not as likely to overheat) under /user/lib:

jlpoole@eos ~/libedgetpu $ ls -la /usr/lib/libedge*
lrwxrwxrwx 1 root root 26 Dec 24 14:32 /usr/lib/libedgetpu.so.1 -> /usr/lib/libedgetpu.so.1.0
-rwxr-xr-x 1 root root 1057240 Dec 24 19:28 /usr/lib/libedgetpu.so.1.0
jlpoole@eos ~/libedgetpu $

Then I proceeded to build the Tflite Python module which was straight forward. I installed the built module as user jlpoole, but the the Coral bound was not connected to. I ended up having to install the module as root and then running the test script as root in order to successfully interface with the coral board.

To Build on Raspberry Pi 4B

Same kind of steps above, except I renamed all instances of "k8" to "aarch64" in all the files I edited above plus the two files I added under directory toolchain.

And, most importantly, I set an environmental variable in the console where I run "make":

Code: Select all

export CPU=aarch64

Again, on the Raspberry, I had to run the test scripts as root, I could not connect to the Coral board as user jlpoole.