Hi Adnan,
We need to make a build for arm-buildroot-linux-musleabihf. How can we get the libLexActivator lib ?
Have a good day,
Pat.
Hi Pat,
We may need some time for this build. Will keep you posted.
Regards,
Adnan
Very good, thanks. Do you have any rough estimate when it may be ready?
Have a good day,
Pat
It may take 2-3 weeks.
Ok thanks.
Looking forward your update.
Pat.
Hi Adnan,
First of all, happy new year.
Just wanted to check whether you are still on track on this topic.
Pat
Hi Pat,
Thanks!
Yes, we have this activity on our priority list. We will keep you posted.
Regards,
Ahmad.
Hi Adnan,
When do you think you will provide a arm-buildroot-linux-musleabihf build?
We committed to provide a demo app to our customer beginning of next week.
Pat
Hi Pat,
Thanks a lot for your patience!
For now, build for arm-linux-musleabihf, arm-linux-musleabi and aarch64-linux-musl can be downloaded from the link below:
We are releasing a new version of lexactivator this week and then onwards these architectures will be supported too.
Regards,
Ahmad.
Hi Ahmad,
Thanks for the build.
I gave a try but I’m facing some link issues. While I’m going on my investigations trying to figure out them, I wanted to share them with you to see if it rings a bell (this is just an excerpt of the missing symbols, there are much more lines as the same symbol can be missing for different modules):
LexBotan.cpp:(.text+0x127c): undefined reference to std::__throw_bad_array_new_length()' LexBotan.cpp:(.text+0x11f64): undefined reference to __select_time64’
LexBotan.cpp:(.text+0x18e88): undefined reference to __time64' LexBotan.cpp:(.text+0x18ea4): undefined reference to __gmtime64_r’
LexBotan.cpp:(.text+0x18f80): undefined reference to __clock_gettime64' LexBotan.cpp:(.text+0x235e8): undefined reference to __getrusage_time64’
LexBotan.cpp:(.text+0x236a4): undefined reference to __stat_time64' LexAbstraction.cpp:(.text+0x738): undefined reference to __stat_time64’
timing.c:(.text+0x30): undefined reference to `__gettimeofday_time64’
I’m guessing that this is something to do with the toolchain used (and the libc). Which toolchain have you used? Is it a generic toolchain or a toolchain you built yourself?
Pat
What is the Alpine distro version you are using? Is the dynamic build working in your case?
Hi Adnan,
Dynamic build is building (don’t know whether it works as I don’t have any device to test for now).
I’m using a toolchain working under ubuntu:
arm-buildroot-linux-musleabihf-g++ --version
arm-buildroot-linux-musleabihf-g++.br_real (Buildroot 2019.02.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Does it help to understand the static link issues?
Pat
Hi Pat,
We are trying to narrow down the problem related to the static build. We have tested both the dynamic and the static build using the docker image mentioned in the readme file and it works completely fine.
Can you try using the same docker image?
Regards,
Ahmad.
Hi Ahmad
Does the docker image support multiplatform?
I haven’t been able to select other platform than linux/amd64:
For instance:
- docker run -it --rm cryptlex/alpine-builder-arm:1 uname -m
x86_64 - docker run -it --rm --platform linux/arm/v7 cryptlex/alpine-builder-arm:1 uname -m
…
docker: Error response from daemon: image with reference cryptlex/alpine-builder-arm:1 was found but does not match the specified platform: wanted linux/arm/v7, actual: linux/amd64.
Pat
Hi Pat,
The provided docker image is an x86_64 image and it has cross compilers for all arm architectures.
We have used the latest release of the build root. We will check it with the version you are using. Maybe that is causing an issue with the static link.
Regards,
Ahmad.
Hi Pat,
Any update on this issue from your end?
Hi Ahmad,
Sorry I sent an email a few days ago but looks like you didn’t receive it.
Are you able to test the musl build for arm platform? Are you using a real device or a docker image for that?
I 'm still struggling with musl build and test. I have the feeling that all components should be built with the same toolchain, especially if the end user is using a toolchain built by buildroot. Does it make sense?
If so, is it something doable, I mean, you making a build with the toolchain we received from the end user?
Pat
Hi Pat,
If the .so file is compiling fine, then it should most probably work. You actually need to run the complied app on a real system to see if it is working. Alternatively, you can also use Qemu to simulate an armhf machine and use Docker armhf image of any OS to run your app. This may help:
https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/
Hi Adnan and Ahmad,
Sorry to insist, but can the LexActivator lib be built with a customer toolchain? We are stuck with this use case, and we think that we will be facing to this scenario again in future, I mean, when some of our customers use linux toolchain customized to their needs.
Pat
Hi Pat,
Can you please share the exact error you are getting at the time of compilation/running (when using .so file) so we can help you with this?
Regards,
Adnan