Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BSEC integration problem on gcc Cortex A7

    BSEC integration problem on gcc Cortex A7

    New Poster

    I'm having two problems while attempting to integrate BSEC on for gcc Cortex A7. I'm trying to build an application which links to a shared library which includes libalgobsec.a and some other code.  I'm running into problems during the linking phase. I have created a proof of concept that doesn't use BSEC so that I can demonstrate a possible solution (in addition to the problem).  I can't solve the problem with BSEC because I don't have the source code.

    The structure of the proof of concept is:

    test{main.c} ->{saythings.c, libgreeting.a{hello.c, goodbye.c}}

    When I build the proof of concept with my ARM Cortex A7 toolchain, I get the following output:

    $ make
    arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c -Ilibsaythings main.c
    arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c -Ilibgreeting -fPIC -o libsaythings/saythings.o libsaythings/saythings.c
    arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c  -o libgreeting/hello.o libgreeting/hello.c
    arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -c  -o libgreeting/goodbye.o libgreeting/goodbye.c
    ar rcs libgreeting/libgreeting.a libgreeting/hello.o libgreeting/goodbye.o
    arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon  -mfloat-abi=softfp --sysroot=/opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/armv7a-neon-poky-linux-gnueabi -shared -o libsaythings/ libsaythings/saythings.o libgreeting/libgreeting.a
    /opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.2.0/real-ld: libgreeting/libgreeting.a(hello.o): relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    libgreeting/libgreeting.a: error adding symbols: Bad value
    collect2: error: ld returned 1 exit status
    Makefile:20: recipe for target 'libsaythings/' failed
    make: *** [libsaythings/] Error 1

    If I then run "make clean" and set STATIC_LIB_OPTS=-fPIC in the Makefile and try again, the build is successful.

    So a possible solution is for Bosch to compile the .c files within BSEC using -fPIC.  Would Bosch be willing to do this for the gcc Cortex A7 version?  I'm also open to hearing other suggestions.  The problem goes away if you structure the application like this:

    test{main.c, saythings.c, libgreeting.a{hello.c, goodbye.c}}

    I consider that a non-solution to the problem since it prevents the use of any shared libraries on top of BSEC.


    The second (more minor) problem I'm having is that I think libalgobsec.a was built with -fshort-enums.  This causes warnings like this to be emitted when the code that links to it is not built with -fshort-enums.

    /opt/swi/y22-ext-SWI9X07Y_02.22.00.00/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.2.0/real-ld: warning: libgreeting/libgreeting.a(goodbye.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail

    Is there a reason why the gcc Cortex A7 version of BSEC is built with -fshort-enums?  I think it would be better to build without that option.  The gcc manpage has this to say about -fshort-enum:

    Warning: the -fshort-enums switch causes GCC to generate code that is not binary compatible with code generated without that switch.  Use it to conform to a non-default application binary interface.

    4 REPLIES 4

    Community Moderator
    Community Moderator

    Attached is a release of BSEC compiled with the following options: '-c -std=c99 -march=armv7-a -fPIC -mthumb -O2 -fdata-sections -fno-builtin -fno-common'. Please let us know if you are still facing any compilation issues.

    The version attached to the previous reply seems to work.  I still get the warnings about the variable sized enums though.  Would you consider changing future releases of BSEC for Cortex A7 to be built such that they are relocatable by default?  Otherwise, I think I will have to request a new build whenever a new version of BSEC is released.

    I'm trying to link the Cortex-A7 BSEC library in my project but I am seeing the following issues:

    1. Relocation errors, e.g. libalgobsec.a(bsec_interface.o): relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    2. Enum warnings e.g. libalgobsec.a(applyScalarFunctionInPlace.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
    3. VFP errors e.g. error: bin\ARM\Debug\HighLevelApp.out uses VFP register arguments, libraries\BSEC\libalgobsec.a(bsec_codegen_do_steps.o) does not

    If I use the modified library linked above ( then problem 1 is resolved, but problems 2 and 3 still exist.

    I would agree with the original poster that the standard Cortex-A7 library should be compiled using the -fPIC -fno-short-enums options.

    Can anyone assist me to get past the VFP errors?

    For reference, I'm using an Azure Sphere board with a BME680, compiling my project in Visual Studio with the SDK preview:

    Here are my(default) gcc options:

    -c -x c -I DRIVERS/BME680 -I LIBRARIES -I DRIVERS -I "C:\PROGRAM FILES (X86)\MICROSOFT AZURE SPHERE SDK\SYSROOTS\2+BETA1905\USR\INCLUDE" -I ..\HARDWARE\AVNET_MT3620_SK\INC -I "C:\PROGRAM FILES (X86)\MICROSOFT AZURE SPHERE SDK\SYSROOTS\2+BETA1905\USR\INCLUDE" -g2 -gdwarf-2 -o "OBJ\ARM\DEBUG\AZURE_IOT_UTILITIES.O" -Wall -W"strict-prototypes" -Wswitch -W"no-deprecated-declarations" -W"empty-body" -Wconversion -W"return-type" -Wparentheses -W"no-pointer-sign" -W"no-format" -Wuninitialized -W"unreachable-code" -W"unused-function" -W"unused-value" -W"unused-variable" -W"deprecated-declarations" -O0 -fno-strict-aliasing -fno-omit-frame-pointer -D_POSIX_C_SOURCE -fno-exceptions -std=c11 -fstack-protector-strong -Werror=implicit-function-declaration -B "C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\2+Beta1905\tools\gcc" -march=armv7ve -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 -ggdb -fPIC -ffunction-sections -fdata-sections --sysroot="C:\Program Files (x86)\Microsoft Azure Sphere SDK\Sysroots\2+Beta1905" 


    I also tried to link to the armhf library, available in the COINES download (

    That library only gives me the relocation errors, so if you can provide a version of that compiled with -fPIC then I think it might work.