We need to make a build for arm-buildroot-linux-musleabihf. How can we get the libLexActivator lib ?
Have a good day,
We may need some time for this build. Will keep you posted.
Very good, thanks. Do you have any rough estimate when it may be ready?
Have a good day,
It may take 2-3 weeks.
Looking forward your update.
First of all, happy new year.
Just wanted to check whether you are still on track on this topic.
Yes, we have this activity on our priority list. We will keep you posted.
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.
Thanks a lot for your patience!
For now, build for
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.
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?
What is the Alpine distro version you are using? Is the dynamic build working in your case?
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++.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?
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?
Does the docker image support multiplatform?
I haven’t been able to select other platform than linux/amd64:
- docker run -it --rm cryptlex/alpine-builder-arm:1 uname -m
- 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.
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.
Any update on this issue from your end?
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?
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:
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.
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?