Spurred on by some very good progress compiling and testing a lot of the example code with an OAK1 plugged in to a laptop. Reading through some of the examples source has been great for helping to understand the architecture and structure of the hardware.

I'm about to embark on the same exercise cross-compiling code for my OAKD-CM4.
I thought the most logical thing to do would be start with the depthai-core-example again, as it's a good foundation to grow from once the end-to-end build process is successfully mastered.

I'm using VSCode as it seems much better suited to handling CMake than Eclipse (sadly). I've hit a slight obstacle with the armhf build for the CM4, as it needs libusb. Rather than clutter the post with the entire log, here are the last few entries...

[cmake] CMake Error at XLink.cmake:27 (message):
[cmake]   libusb is required
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:8 (include)__

I guess it would make it incompatible with running on windows if your team published the depthai-core-example with the libusb module, so what's the best or recommended way to add the libusb source to the depthai-core-example ?

Let me know if I need to post / attach any further diagnostic info.
Thanks.

Hi @mikegardner

XLink is the dependency that provides communication between DepthAI host and our devices.
Its dependent on libusb, but doesn't include it by itself. (Might do in future, TBD)

As XLink is 3rdparty dependency and it unfortunately isn't well written to cover wide range of different environments, so you'll have to help XLink find the libusb library.

To do that, you should add to a toolchain file, which specifies various cross compilation options already like:

  • Which compiler
  • Path to rootfs
  • ...

The paths to target device libusb library using CMake variable like CMAKE_PREFIX_PATH or CMAKE_SYSTE_PREFIX_PATH (https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html) which is used by find_path and find_library calls in XLink.
Or directly setting LIBUSB_INCLUDE_DIR and LIBUSB_LIBRARY variables to the their respective paths.

Eitherway, you'll need the before mentioned toolchain and apply it while compiling the example using -D CMAKE_TOOLCHAIN_FILE=[path/to/toolchain] as well as having the actual library (ARM binaries not host x86_64) available somewhere for the CMake to find them (preferably you just install on the system itself using apt-get and then find them in the mounted rootfs of RPi.

Let me know how it goes,
Martin Peterlin


    themarpe Thanks for the full explanation, I understand the need for the armhf library rather than the x86_64, although it does raise a question in my mind: why can't the libusb package be added to the dependencies configuration so that it's fully built alongside the depth-core-example (for example, similar to the hunter_add_package(libarchive-luxonis) entry)? Sorry if it's a dumb question, I'm still on a learning curve with CMake, and I'm trying to establish a strategic approach to finalising my development environment.

    Anyway, I'll give the suggestion a try and report back as soon as I can, might be 2 or 3 days due to workload.

        mikegardner

        why can't the libusb package be added to the dependencies configuration so that it's fully built alongside the depth-core-example (for example, similar to the hunter_add_package(libarchive-luxonis) entry)?

        It can, but isn't yet done because that was the initial behavior - to find the system libusb.
        As mentioned above, I'll refactor this most likely soon with some additional XLink improvements, afterwards this won't be needed anymore.

        Sounds good🙂

          13 days later

          Folks, just a very brief update. I am still working on this, making steady progress fitting it in with work commitments. Latest challenge is related the differences with the BZip2 package on the 2 platforms. I'll hopefully have some time this week to investigate it further...

          _[cmake] CMake Error at depthai-core/cmake/depthaiDependencies.cmake:21 (find_package):
[cmake]   Could not find a configuration file for package "BZip2" that is compatible
[cmake]   with requested version "".
[cmake]   The following configuration files were considered but not accepted:
[cmake]     /home/mike/.hunter/_Base/062a19a/64dcd41/f3a139e/Install/lib/cmake/BZip2/BZip2Config.cmake, version: 
1.0.6 (64bit)_
          2 years later

          Has anyone been able to accomplish this yet? I am doing something similar...

          I want to add all libraries (including opencv and depthai-core) as GitHub submodules, compiling them statically (so everything is bundled together and only a single binary needs to be loaded onto the device). For obvious reasons, I really would like to avoid compiling on the pi itself every time. I am currently working on a Windows 11 device, with the compilers on a WSL2 instance.

          I've used the Python API for a while now to support the project development, but I have a lot of embedded C background and just feel a lot more comfortable developing in C/C++.

          I would love to just get my workflow set up and be able to write code in C/C++, cross-compile using WSL2, and remotely debug to the Pi/whatever device I want.

            3 months later

            adriaan-mernok
            I'm in the same boat. I would like to cross compile C/C++ application using WSL2.

            Unfortunately I'm struggling with the build of depthai-core.
            I'm able to cross compile libusb, libarchive, opencv, lz4, thrirft, and so on for raspberry pi4 and use it in related projects.
            But depthai-core does not work. I invested already some time couple month ago, and thought to give it another try. But I fail again and it is frustrating.

            Did anybody manage to cross-compile?