AIRunner LoadNetFromTensorFlow protobuf-lite incompatability

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

AIRunner LoadNetFromTensorFlow protobuf-lite incompatability

1,103 Views
pkeane8
Contributor I
For our feature application we have been using codegen to compile a neural network into a static library which is then compiled into a dynamic library.  The network is the loaded using the following generated AIRunner API.
apexStatus = netbuilder::MobileNetv2SSD_BuildGraph(*mNetMSSD, mLApexNetInput, mOutput);
Recently there has been a desire to switch to using LoadNetFromTensorFlow since the feature will be deployed on different vehicles with different variants which has necessitated the use of different neural networks. Using LoadNetFromTensorFlow would be the best option since it minimizes the complexity of deploying the application to vehicles, since the only thing that changes is the protobuf file containing the neural network.
apexStatus = airunner::LoadNetFromTensorFlow(*mNetMSSD, "AutoHitch_DrawBarAndTrailerDetector.pb", mLApexNetInput, mOutput);
However, other third-party libraries are being compiled into the feature application including a dynamic version of protobuf-lite. When I attempt to compile a version of the feature application with LoadNetFromTensorFlow as the API for loading the neural network I cannot compile because of symbol conflicts.
 
/opt/qnx700/host/linux/x86_64/usr/bin/aarch64-unknown-nto-qnx7.0.0-ld: /opt/NXP/s32v234_sdk/libs/dnn/airunner/importer/build-v234ce-qcc-qnx-o/airunner_importer.a(graph.pb-cc.o): undefined reference to symbol '_ZN6google8protobuf8internal9ArenaImpl10AddCleanupEPvPFvS3_E'
/home/edista_local/workspace/external/3rdParty/Production/Ford/analytics_soa/CortexA53-QNX/lib/libprotobuf-lite.so.15: error adding symbols: DSO missing from command line
 
Please correct me if I am wrong but it looks like airunner_importer.a is statically linking some version libprotobuf-lite.a? I am confident the issue is coming from there because the only line I change is MovileNetc2SSD_BuildGraph ----> LoadNetFromTensorFlow. I suspect there are no conflicts in the previous case because the symbols that are not needed are being optimized out by the compiler.
 
The only way around this I can see at the moment is ensuring that the two 3rd-party libraries which are using libprotobuf-lite have versions which don't conflict. However this is going to be time consuming for either NXP or Ford so I don't think this possible at the moment. 
 
Any other suggestions for navigating this problem?
 
For the record we are using AIRunner version 2.1.1 and VSDK 1.5.4.
 
Thanks,
 

Patrick Keane

ADAS Ford Motor Company

0 Kudos
0 Replies