Removing DL_ARM_NEON_OPTIONAL define from global chromium-efl.gypi file, because it causes build break in debug build.
Defining DL_ARM_NEON_OPTIONAL makes omxSP_FFTFwd_RToCCS_F32 and omxSP_FFTInv_CCSToR_F32 symbols
refer to function pointers, which are defined in src/third_party/openmax_dl/dl/sp/src/arm/detect.c ,
but this file is Android-specific and is not compiled for Tizen. Fortunately,
omxSP_FFTFwd_RToCCS_F32 and omxSP_FFTInv_CCSToR_F32 functions are used only in code
in src/third_party/webrtc/common_audio/real_fourier.cc , which turns out to be never used
and linker optimizes it away. But in debug mode it causes linking error.
The define was once needed when we didn't have arm_neon=1 in gyp. This was causing
that in openmax package (src/third_party/openmax_dl/dl/dl.gyp) neither DL_ARM_NEON nor
DL_ARM_NEON_OPTIONAL were defined. It resulted in omxSP_FFTFwd_RToCCS_F32 and
omxSP_FFTInv_CCSToR_F32 symbol being defined to VFP versions of the functions, and build error.
But now we have arm_neon=1 and this isn't needed anymore. omxSP_FFTFwd_RToCCS_F32 and
omxSP_FFTInv_CCSToR_F32 symbols will be defined to NEON versions of the functions
without runtime detection.
Reviewed by: Kamil Klimek, Piotr Tworek, SeungSeop Park, arno renevier
Change-Id: Id1f9c3d87f19c472a00454abb7c63cf02ceabfb3
Signed-off-by: Wojciech Wiśniewski <w.wisniewski@samsung.com>
['building_for_tizen==1', {
'defines': [
'OS_TIZEN=1',
- 'DL_ARM_NEON_OPTIONAL=1', # TODO: Temporary fix for M40 build break due to wrong selection of
- # omxSP_FFTInv_CCSToR_F32_vfp in src/third_party/openmax_dl/dl/sp/api/omxSP.h:2558 .
- # Remove this line after a more proper solution is found.
'TIZEN_MULTIMEDIA_PIXMAP_SUPPORT=1',
'TIZEN_CAPI_PLAYER_SUPPORT=1',
],