I'm trying to install bme68x on 64-bit architecture Raspberry Pi 4.
I tryied to use the BSEC 22.214.171.124 downloaded from your webpage and I followed all the steps explained in this repository but I get some errors when launching the setup.py installation. Following the screenshot of the error I get
Can you help me?
In the following image there is the specifics about my compiler
Moreover, I tryed to use the 64-bit library that you suggested but I still get an error when launching the installation via setup.py. I get the following error
Any suggestion on how to resolve this problem? Shouldn't I use the library from Raspberry forlder instead of gcc one considering that I'm trying to install the library on a Raspberry Pi 4?
See it from you latest log, you haven't compile your code with "BSEC\BSEC126.96.36.199_Generic_Release_23012023\algo\normal_version\bin\RaspberryPi\PiFour_Armv8\libalgobsec.a", this library work for ARMV8 architecture.
We would like to know your host architecture of your Raspberry Pi 4?
Please provide the download link of the compiler so that we can setup a compilation environment to try compiling.
Hi There are more people trying to get this working with PI 4 and 64 bit raspbian, so I would like to revisit this question.
In BSEC2 188.8.131.52 there is a PiFour_Armv8 version of algobsec and I can see that it is AArch64 and it is relocatable, just like the ArmV6 libraries.
Raspbian bullseye (Debian 11 64 bit) provides gcc-10 and this is what gcc-10 -v prints out:
$ gcc-10 -v Using built-in specs. COLLECT_GCC=gcc-10 COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/10/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6)
The problem we are having is that the linker is failing to produce the final .so output, and is complaining about relocation - here is one example
/usr/bin/ld: BSEC184.108.40.206_Generic_Release_23012023/algo/normal_version/bin/RaspberryPi/PiFour_Armv8/libalgobsec.a(bsec_codegen_do_steps.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `uv2' which may bind externally can not be used when making a shared object; recompile with -fPIC
All of these fatal errors are to do with linking algobsec.a to the rest of the code. All the other xx.c code has produced xx.o files that are relocatable, so all the parts are there, but the linker is not happy.
This is the final command that shoudl produce the .so file
/bin/aarch64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g -fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-PN012d/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-aarch64-3.9/BME68x-Sensor-API/bme68x.o build/temp.linux-aarch64-3.9/bme68xmodule.o build/temp.linux-aarch64-3.9/internal_functions.o -L/usr/lib/aarch64-linux-gnu -L/usr/lib -L/usr/local/lib -L/lib/aarch64-linux-gnu -LBSEC220.127.116.11_Generic_Release_23012023/algo/normal_version/bin/RaspberryPi/PiFour_Armv8 -lpthread -lm -lrt -o build/lib.linux-aarch64-3.9/bme68x.cpython-39-aarch64-linux-gnu.so -lalgobsec
I have been playing around with the order of linking, but not made any difference.
Would appreciate your input.
P.S. I know we have lots of other 32/64 bit issues to fix, but I wanted to start with something that works and then blows up when running.