TeresaARM
commented
2 years ago Hi @ggardet which command are you using for building, have you tried a clean build?
Closed ggardet closed 2 years ago
TeresaARM
commented
2 years ago Hi @ggardet which command are you using for building, have you tried a clean build?
ggardet
commented
2 years ago Hi @ggardet which command are you using for building, have you tried a clean build?
The cmake command is:
[ 146s] + /usr/bin/cmake /home/abuild/rpmbuild/BUILD/armnn-22.02/. '-GUnix Makefiles' -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_INSTALL_LIBDIR:PATH=lib64 -DCMAKE_INSTALL_LIBEXECDIR=/usr/libexec -DCMAKE_BUILD_TYPE=RelWithDebInfo '-DCMAKE_C_FLAGS=-mbranch-protection=standard -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -DNDEBUG' '-DCMAKE_CXX_FLAGS=-mbranch-protection=standard -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -DNDEBUG' '-DCMAKE_Fortran_FLAGS=-mbranch-protection=standard -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -DNDEBUG' '-DCMAKE_EXE_LINKER_FLAGS=-flto=auto -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' '-DCMAKE_MODULE_LINKER_FLAGS=-flto=auto -Wl,--as-needed' '-DCMAKE_SHARED_LINKER_FLAGS=-flto=auto -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' -DLIB_SUFFIX=64 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF -DCMAKE_COLOR_MAKEFILE:BOOL=OFF -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_MODULES_INSTALL_DIR=/usr/lib64/cmake/armnn -DCMAKE_SKIP_RPATH=True -DSHARED_BOOST=1 '-DCMAKE_CXX_FLAGS:STRING=-mbranch-protection=standard -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -pthread ' -DBOOST_LIBRARYDIR=/usr/lib64 -DBUILD_ONNX_PARSER=OFF -DBUILD_ARMNN_SERIALIZER=ON -DFLATC_DIR=/usr/bin -DFLATBUFFERS_INCLUDE_PATH=/usr/include -DBUILD_TF_LITE_PARSER=ON -DTfLite_Schema_INCLUDE_PATH=/usr/include/tensorflow/lite/schema/ -DTF_LITE_SCHEMA_INCLUDE_PATH=/usr/include/tensorflow/lite/schema/ -DARMCOMPUTE_INCLUDE=/usr/include -DHALF_INCLUDE=/usr/include/half -DARMCOMPUTE_BUILD_DIR=/usr/lib64 -DARMCOMPUTE_ROOT=/usr -DARMCOMPUTENEON=ON -DARMCOMPUTECL=OFF -DTHIRD_PARTY_INCLUDE_DIRS=/usr/include -DBUILD_SAMPLE_APP=ON -DBUILD_UNIT_TESTS=ON -DBUILD_TESTS=ON -DBUILD_PYTHON_WHL=OFF -DBUILD_PYTHON_SRC=OFF -DBUILD_ARMNN_EXAMPLES=OFFThe build folder is clean.
FrancisMurtagh-arm
commented
2 years ago Hi @ggardet,
What version of Flatbuffers are you using?
Regards, Francis.
ggardet
commented
2 years ago What version of Flatbuffers are you using?
Flatbuffers 2.0.0
FrancisMurtagh-arm
commented
2 years ago Hi @ggardet,
Did OpenSuse bump Flatbuffers recently? We support Flatbuffers 1.12; is there any way you can try it with that version?
Regards, Francis.
ggardet
commented
2 years ago flatbuffers package has been updated from 1.12.0 to 2.0.0 10 months ago. But LTO was disabled for previous versions as well.
I cannot test easily with previous package.
Please note that armnn 22.02 builds fine without LTO.
MatthewARM
commented
2 years ago I would guess from the error messages, that ArmnnSchema_generated.h has created more than one definition of e.g. ConstTensorData. One definition is at line 650 and one at 646. In my build there's only one definition. @ggardet could you have a look at those definitions or maybe post a snippet from your ArmnnSchema_generated.h file? I can theorise four possibilities:
a) The two definitions are surrounded by preprocessor conditions, and somehow during the build of libarmnnSerializer.so.28.0 some of the translation units are getting one of the definitions and some are getting the other. This seems unlikely as all of the diagnostics refer to SerializerUtils.cpp, no other source file is mentioned, so unless SerializerUtils.cpp is compiled more than once with different options I can't see how it can be this. b) ArmnnSchema_generated.h only has one definition, and somehow an old artifact with an incompatible definition is partially getting used in the build process. c) ArmnnSchema_generated.h is getting generated more than once during the build process, with different options to flatc, causing different source to be generated. Again I would have expected other .cpp files to appear in the diagnostics, as per theory (a). d) flatc is generating multiple definitions and they are not surrounded by preprocessor conditions. I don't think it can be this, as then I would have expected all builds to fail, not just LTO.
MatthewARM
commented
2 years ago Ah yes, it's probably (c). ArmnnSchema_generated.h is both checked-in and generated during the build. That's asking for trouble.
MatthewARM
commented
2 years ago ArmnnSchema_generated.h was checked in to the repo in this change https://review.mlplatform.org/c/ml/armnn/+/4850 so that the serializer could build from Android.mk without invoking flatc.
MatthewARM
commented
2 years ago AOSP now includes flatbuffers, so I think the proper fix here is to:
MatthewARM
commented
2 years ago If that's not possible for some reason, then the alternative less-good solution would be:
I really don't like this solution as it increases the dependences between android-nn-driver and armnn for AOSP builds, which violates modularity.
catcor01
commented
2 years ago Hello @ggardet,
I'm closing this due to inactivity. If you still need help with this then please create a new ticket.
Kind Regards, Cathal.
Build of armnn 22.02 fails with LTO enabled: