• State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 16 subscribers
  • Views 4385 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[Arm NN on Cortex-A9] Static build leads to "None of the preferred backends [CpuRef ] are supported" error at runtime

Nicolas V.

Hello ArmNN experts,
I'm currently facing an issue at runtime when using a statically built ArmNN lib.

I have been able to build a STATIC version of libarmnn with all dependancies and then build my own app for a Wandboard target (armv7).
At runtime I got this error: "ERROR: None of the preferred backends [CpuRef ] are supported. Current platform provides []"

When I compile SHARED libraries (*.so) the exact same app is running fine, and the inference is done as expected.

ArmNN version: 21.02
Model/Target: TFLite on armv7
Build options: cmake .. -DCMAKE_LINKER=/usr/bin/arm-linux-gnueabihf-ld -DCMAKE_C_COMPILER=/usr/bin/arm-linux-gnueabihf-gcc -DCMAKE_CXX_COMPILER=/usr/bin/arm-linux-gnueabihf-g++ -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=14 -DCMAKE_CXX_FLAGS=-mfpu=neon -DARMCOMPUTE_ROOT=$BASEDIR/ComputeLibrary -DARMCOMPUTE_BUILD_DIR=$BASEDIR/ComputeLibrary/build -DBOOST_ROOT=$BASEDIR/boost_1_64_0 -DTF_GENERATED_SOURCES=$BASEDIR/tensorflow-protobuf -DBUILD_TF_PARSER=0 -DBUILD_ONNX_PARSER=0 -DONNX_GENERATED_SOURCES=$BASEDIR/onnx -DBUILD_TF_LITE_PARSER=1 -DTF_LITE_GENERATED_PATH=$BASEDIR/tflite -DFLATBUFFERS_ROOT=$BASEDIR/flatbuffers-arm32 -DFLATC_DIR=$BASEDIR/flatbuffers/build -DPROTOBUF_ROOT=$BASEDIR/protobuf-arm -DARMCOMPUTENEON=1 -DARMNNREF=1

Does anyone have an idea of a fix or additionnal investigations ??
Thanks!!

Regards,
Nicolas

Parents
  • 0

    Here is my solution:

    To pull in CpuRef backend, I suggest to add a dummy function RefRegistryInitializer() in RefRegistryInitializer.cpp, like this:

    void RefRegistryInitializer(void)
    {
        // This function must be called so that the underlying backend gets added to the system!
    }

    Add its prototype to BackendRegistry.hpp.

    To pull in CpuAcc backend, I suggest to add a dummy function NeonRegistryInitializer() in NeonRegistryInitializer.cpp, like this:

    void NeonRegistryInitializer(void)
    {
        // This function must be called so that the underlying backend gets added to the system!
    }

    Add its prototype to BackendRegistry.hpp.

    Then rebuild your static libarmnn.a library.

    Finally, in your application, call:

       RefRegistryInitializer();
       NeonRegistryInitializer();

    Rebuild your application, and the linker will pull in both backends in it.

    P.S. Has the Arm NN team have ever tested applications using static libarmnn.a library?

Reply
  • 0

    Here is my solution:

    To pull in CpuRef backend, I suggest to add a dummy function RefRegistryInitializer() in RefRegistryInitializer.cpp, like this:

    void RefRegistryInitializer(void)
    {
        // This function must be called so that the underlying backend gets added to the system!
    }

    Add its prototype to BackendRegistry.hpp.

    To pull in CpuAcc backend, I suggest to add a dummy function NeonRegistryInitializer() in NeonRegistryInitializer.cpp, like this:

    void NeonRegistryInitializer(void)
    {
        // This function must be called so that the underlying backend gets added to the system!
    }

    Add its prototype to BackendRegistry.hpp.

    Then rebuild your static libarmnn.a library.

    Finally, in your application, call:

       RefRegistryInitializer();
       NeonRegistryInitializer();

    Rebuild your application, and the linker will pull in both backends in it.

    P.S. Has the Arm NN team have ever tested applications using static libarmnn.a library?

Children
No data