Building a custom docker image with VOXL libs
-
Hi,
I am trying to build a docker image which includes both my own project libs and the required modal_pipe_*.h files.
First, I built an Ubuntu20.04-ARM64 image with all the required libraries on my side. Then, I tried adding the VOXL libs by cloning
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-qvio-server and running $ ./install_build_deps.sh qrb5165 dev .
This, however, leads to an issue where while the dependencies are installed, there are not compatible with the system./usr/bin/ld: skipping incompatible /usr/lib/gcc/aarch64-linux-gnu/9/../../../../lib/libmodal_pipe.so when searching for -lmodal_pipe
/usr/bin/ld: skipping incompatible /lib/../lib/libmodal_pipe.so when searching for -lmodal_pipe
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libmodal_pipe.so when searching for -lmodal_pipe
/usr/bin/ld: skipping incompatible /usr/lib/gcc/aarch64-linux-gnu/9/../../../libmodal_pipe.so when searching for -lmodal_pipe
/usr/bin/ld: skipping incompatible /lib/libmodal_pipe.so when searching for -lmodal_pipe
/usr/bin/ld: skipping incompatible /usr/lib/libmodal_pipe.so when searching for -lmodal_pipeWhere trying to inspect the files -
$ file /usr/lib/libmodal_pipe.so /usr/lib/libmodal_pipe.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=21cd25b6d5b22353c369a8dad181d4acdbbbbe6f, not strippedEither I am doing something wrong, or the installation script is pointing to the wrong place.
I did try to inspect the dev repo http://voxl-packages.modalai.com/dists/apq8096/dev/binary-arm64/ which seems to have only 64bit debians, so I might be doing something wrong.
-
@ShauliXtend
Well, I did manage to link the installed 64bit libraries by forcing an overwrite over the 32bit libs. I am not sure why using LD_LIBRARY_PATH to point at /usr/lib64 did not simply work.65 ln -sf /usr/lib64/libmodal_pipe.so /usr/lib/libmodal_pipe.so
66 ln -sf /usr/lib64/libmodal_json.so /usr/lib/libmodal_json.so
67 ln -sf /usr/lib64/libmodal_exposure.so /usr/lib/libmodal_exposure.so
70 ln -sf /usr/lib64/libvoxl_common_config.so /usr/lib/libvoxl_common_config.soI was not able to overwrite the /usr/lib/libmv1.so library which is missing the 64bit version.
-
@ShauliXtend You might want to just start with one of our docker images and add your projects on top of that.
-
Also the QVIO build requires proprietary headers and libs (the MV lib that you've noted here) that we can't publish without a EULA, so they're only included in our system images and emulator docker images (as opposed to the cross one).
-
@tom said in Building a custom docker image with VOXL libs:
@ShauliXtend You might want to just start with one of our docker images and add your projects on top of that.
Hi @tom,
Unfortunately, I have found out that working with the containers supplied above is highly uncomfortable. They are wrapped around too many scripts and logics which hinder my progress. Thanks for the offer. If I give up, I'll probably give it a try. -
@Alex-Gardner said in Building a custom docker image with VOXL libs:
Also the QVIO build requires proprietary headers and libs (the MV lib that you've noted here) that we can't publish without a EULA, so they're only included in our system images and emulator docker images (as opposed to the cross one).
Hi @Alex-Gardner ,
I figured this might be the issue. I did see that even on the VOXL itself you use 32bit libraries while the system is 64bit. I am able to mount the file to my own container but the 32bit issue is still there, obviously.
I am not a CMake expert, but maybe there is a way to still use the 32bit file.
Thanks,
Shauli -
@ShauliXtend said in Building a custom docker image with VOXL libs:
on the VOXL itself you use 32bit libraries while the system is 64bit
Yes, unfortunately the QVIO algorithm is proprietary to qualcomm, we don't even have the source, just the 32 bit binaries that they've provided.
maybe there is a way to still use the 32bit file
You'll need to compile a 32-bit program to use a 32-bit library, there's unfortunately no way around this without some sort of inter-process communication (hence our standalone qvio-server)