[onert] Trouble building the runtime

[tomdol]

Hi,

I'm trying to build the runtime including its Python API and while it worked for me some time ago now I'm getting the following error:

/home/t.dolbniak/projects/one/Product/obj/overlay/include/loco/IR/TensorIndex.h:20:10: fatal error: nncc/core/ADT/tensor/Index.h: No such file or directory
   20 | #include <nncc/core/ADT/tensor/Index.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                 from /home/t.dolbniak/projects/one/runtime/onert/odc/Embedder.cc:17:
/home/t.dolbniak/projects/one/Product/obj/overlay/include/loco/IR/TensorIndex.h:20:10: fatal error: nncc/core/ADT/tensor/Index.h: No such file or directory
   20 | #include <nncc/core/ADT/tensor/Index.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Prior to building the runtime, I've built the compiler with ./nnas create-package --prefix Product/obj/overlay and then I attempted to execute:

./nnfw configure
./nnfw build

Is there anything wrong with the steps I'm executing? According to the howto docs it should be possible to build the runtime this way (although it doesn't mention that the compiler needs to be built - I've done it because I was getting other kinds of errors about the dependencies).

Any hints will be very appreciated.

[tomdol]

@Samsung/one_onert could you please take a look?

[chunseoklee]

In fresh state, I prefer use "make -f Makefile.template"

[hseok-oh]

./nnas create-package --prefix Product/obj/overlay creates overlay for runtime's on-device compiler module, but it is incomplete overlay. There is missing headers as you commented on build error log. It is compiler packaging issue that install incomplete header set for developer.

As @chunseoklee commented, I recommand to use Makefile.template, or add missing headers manually to overlay. You can check that Makefile.template also copy missing headers on build process.

ONE/Makefile.template

Lines 161 to 165 in 7bc0b8b

	# install angkor TensorIndex and oops InternalExn header (TODO: Remove this)
	@mkdir -p ${OVERLAY_FOLDER}/include/nncc/core/ADT/tensor
	@mkdir -p ${OVERLAY_FOLDER}/include/oops
	@cp compiler/angkor/include/nncc/core/ADT/tensor/Index.h ${OVERLAY_FOLDER}/include/nncc/core/ADT/tensor
	@cp compiler/oops/include/oops/InternalExn.h ${OVERLAY_FOLDER}/include/oops

One other option is not installing compiler overlay for runtime build. Then runtime build process will skip building on-device compiler module.

[tomdol]

Thanks for the explanations! I've tried using the Makefile approach and that worked although I'm still trying to get the Python API in a complete form (the pybind library has been compiled but the remaining files are still missing).

And regarding skipping the compiler installation - I've tried that too by running nnfw but in that case I got this error:

  Imported target "luci::import" includes non-existent path

"LUCI_HEADERS-NOTFOUND"
  in its INTERFACE_INCLUDE_DIRECTORIES.

and the error comes from runtime/onert/odc/CMakeLists.txt which does try to import and link against a few luci targets. Have you by any chance experienced that and know how to resolve it?

[glistening]

@tomdol Could you please open runtime/onert/CMakeLists.txt, then comment out like the following?

add_subdirectory(api)
add_subdirectory(backend)
add_subdirectory(core)
add_subdirectory(loader)
# add_subdirectory(odc)
add_subdirectory(sample)

It will prevent looking runtime/onert/odc/CMakeLists.txt.
I hope it works.

---

Details

As I guess, your build succceed to find Luci (as you do ./nnas create-package...).
It makes your build to try the remainging part of odc build.
It would be better to build toolchain (front-end) and runtime (onert) seperately.
Building both in same directory may make trouble when especially, on-device compiler is on, which depends on front-end modules.

nnfw_find_package(Luci QUIET)
if(NOT Luci_FOUND)
  message(STATUS "Luci not found. Skip onert_odc")
  return()
endif()

file(GLOB_RECURSE SOURCES "*.cc")
file(GLOB_RECURSE TESTS "*.test.cc")
list(REMOVE_ITEM SOURCES ${TESTS})

add_library(onert_odc SHARED ${SOURCES})
target_link_libraries(onert_odc PRIVATE onert_core luci::import luci::export luci::pass luci::loco)

[ragmani]

Try building with:

BUILD_TYPE=release make -f Makefile.template configure build install

To build the runtime (including its Python API) for an x86_64 local machine, you can try:

# In a virtual environment
pip install -U pip setuptools wheel auditwheel

# Configure, build, and install
BUILD_TYPE=release make -f Makefile.template configure build install

# Build a wheel for the Python package
pushd runtime/infra/python
python3 setup.py bdist_wheel --plat-name manylinux_2_28_x86_64

# Alternative: Generate the platform tag automatically from GLIBC version & architecture
# python3 setup.py bdist_wheel --plat-name "manylinux_2_$(ldd --version | awk -F') ' 'NR==1{print $2}' | awk '{print $1}' | cut -d. -f2)_$(uname -m)"

ls -al dist/*.whl
popd

# (Optional) Install the generated wheel
# pip install runtime/infra/python/dist/<your-wheel>.whl

This script hasn’t been tested, so actual behavior may vary depending on your build environment and dependencies.

[tomdol]

Gotcha, I was thinking that setup.py has to be used directly (which is fine and typical approach). Thanks!

And regarding the luci headers problem - this happens when I don't touch anything before running nnfw configure. I suppose there's a step that should be taken before so that all the required files and targets are visible to cmake and using Makefile.template takes care of that.

Perhaps we could update the docs https://github.com/samsung/ONE/blob/master/docs/howto/how-to-build-runtime.md#build-from-source-code-for-ubuntu with such a command. Which one would it be that builds the toolchain (frontend) only that you mentioned, @glistening ? Or am I going in an entirely wrong direction here and the Makefile.template should be the way to go with building?

[ragmani]

Sorry for the delay. Last Friday was a holiday for all of us. And @glistening is on vacation until Wednesday(8/20) and @hseok-oh is out today.

Which one would it be that builds the toolchain (frontend) only that you mentioned, @glistening ? Or am I going in an entirely wrong direction here and the Makefile.template should be the way to go with building?

I’m not sure what your specific build goal is, so it’s hard to judge whether you are going in the wrong direction. However, since odc is not related to the Python API, it should be fine to build it as @glistening suggested. Either approach looks acceptable as long as the build succeeds on the current codebase, so I’d say it’s safe to continue with whichever works for you.

As for the issue of build errors when trying nnfw configure, and whether we should update the docs accordingly, I think it would be best to discuss that once @hseok-oh or @glistening is back.

[tomdol]

No worries, I was off on Friday too :) The ultimate goal is to get the Python API built and following the docs one of the ways described there is to use the nnfw configure and nnfw build to get the runtime compiled first. However it looks like the runtime also needs some prerequisites to be built in advance and that part is not covered in the docs (but it's technically handled when using Makefile.template).

The idea to update the docs is just a loose suggestion to make sure that the steps actually work when executed by anybody.

[ragmani]

Thanks for your information. I think you can discuss it with @hseok-oh tomorrow :)

[hseok-oh]

And regarding skipping the compiler installation - I've tried that too by running nnfw but in that case I got this error:

You may need to clean overlay and CMakeCache.txt generated by previous failed build process.

And https://github.com/samsung/ONE/blob/master/docs/howto/how-to-build-runtime.md#build-from-source-code-for-ubuntu does not describe for python packaging. Using venv on that documentation is for test code generation, not for python packaging. We don't have any documentation for python packaging on docs/howto directory, but you can refer https://github.com/Samsung/ONE/blob/master/runtime/infra/python/README.md.