Documentation : cross compilation for arm #46
Comments
|
cmake newbie, I tried adding : to |
|
Happy that you like LVGL so far. I'm not a CMake expert either, but found that these help:
set(CMAKE_C_COMPILER arm-linux-gnueabi-gcc)
set(CMAKE_CXX_COMPILER arm-linux-gnueabi-g++)
set(CMAKE_C_COMPILER_ID GNU) #Add these
set(CMAKE_CXX_COMPILER_ID GNU)
Seemingly the problem is that the nested CMake files are resetting the After these changes it still doesn't compile for me, but I hope it's only due to my hacky cross compile environment. |
|
@kisvegabor thanks for taking a look at this ! It seems to work : Unfortunately I have to wait a week to try it out on the target machine which I don't have at hand. |
|
Got round to testing it on the device, but it fails to run since it is dynamically linked to a libc6 version that is not the target device : I now have to see if I can figure out static linking, using musl or linking to the older libc6 that is present on the system : any pointers welcome ! |
|
cc @XuNeo @liamHowatt @HanesSciarrone |
|
I'm not sure of how to fix it, but seems you need to tell CMAKE where's the SYSROOT. You can copy out the rootfs from board. If any more issues, I would search for how to cross compile for raspberry-pi. It should give lots of guides. |
|
Hi @arthurlutz, I hope you are ok. I can't say exactly what could be the reason for this error, but maybe the problem could be the GLIBC version mismatch between target and host (build machine). Could you run the |
|
@arthurlutz I think the version of libc that the binary tries to link may be based on the version of the toolchain it was compiled with. I'm not sure how old the Linux on your e-reader is but it may be from the Linux 3.0 that the wiki links. It says to use toolchain version 4.9.4 for v3.4 kernels. I struggled to navigate that Linaro artifact file server but this SO answer has the link to a 4.9.3 toolchain :P Try compiling your LVGL test with a 4.* version of arm-linux-gnueabihf-gcc and see if it's happy with the libc currently on your e-reader. |
|
@HanesSciarrone I am well thank you for asking. Hope you are well too. Ideed I am trying to cross-compile with a different libc6 on the target system : on the build : on the target : |
|
@liamHowatt great tips, thanks so much for looking into this! Unfortunately I can get it to compile : would you have an idea on what I need to change to fix this ? Maybe I can test out the binary produced by your compilation ? |
|
C++17 didn't exist when that compiler was released so it doesn't support the flag Remove And then also change this By doing these things and using yours and kisvegabor's tweaks I was able to get it to compile with the v4 toolchain. Sorry, I hadn't tried to actually compile it until now :P Fingers crossed the glibc versions match! 🤞️ I think XuNeo's suggestion was a good idea if this fails to execute again. |
|
Hi @arthurlutz, thanks for the wish. The command output you ran confirms that the problem is the GLIBC used in the toolchain between the Build system and the target so, the issue is here. The chance of fixing the problem with the liamHowatt suggestion is quite high. But, if it doesn't work you need to download the version of the toolchain used in the target, this information is here: The toolchain version is |
|
I'll try to find toolchain version 4.5.1 while testing @liamHowatt 's solution. Please @arthurlutz, let us know if the solution works. |
|
Hi thanks a lot again for being so thorough with helping me out with this. The changes suggested don't seem to remove all thorvg from the make files, I still get the same errors, here is my diff : ❯ git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index d91b196..a1a89ab 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,6 +1,13 @@
cmake_minimum_required(VERSION 3.10)
project(lvgl)
+set(CMAKE_SYSTEM_NAME Linux)
+set(CMAKE_SYSTEM_PROCESSOR arm)
+set(CMAKE_C_COMPILER /home/arthur/local/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc)
+set(CMAKE_CXX_COMPILER /home/arthur/local/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++)
+
+
+
set(CMAKE_C_STANDARD 99)#C99 # lvgl officially support C99 and above
set(CMAKE_CXX_STANDARD 17)#C17
set(CMAKE_CXX_STANDARD_REQUIRED ON)
@@ -12,6 +19,6 @@ target_include_directories(lvgl PUBLIC ${PROJECT_SOURCE_DIR})
add_executable(main main.c mouse_cursor_icon.c)
-target_link_libraries(main lvgl lvgl::examples lvgl::demos lvgl::thorvg ${SDL2_LIBRARIES} m pthread)
+target_link_libraries(main lvgl lvgl::examples lvgl::demos ${SDL2_LIBRARIES} m pthread)
add_custom_target (run COMMAND ${EXECUTABLE_OUTPUT_PATH}/main DEPENDS main)
diff --git a/lv_conf.h b/lv_conf.h
index 822b2a3..2e93e4e 100644
--- a/lv_conf.h
+++ b/lv_conf.h
@@ -693,7 +693,7 @@
#define LV_USE_VECTOR_GRAPHIC 1
/* Enable ThorVG (vector graphics library) from the src/libs folder */
-#define LV_USE_THORVG_INTERNAL 1
+#define LV_USE_THORVG_INTERNAL 0
/* Enable ThorVG by assuming that its installed and linked to the project */
#define LV_USE_THORVG_EXTERNAL 0
diff --git a/lvgl b/lvgl
--- a/lvgl
+++ b/lvgl
@@ -1 +1 @@
-Subproject commit 5c9a0cc017dd23b2103dbc6b88fb155193020187
+Subproject commit 5c9a0cc017dd23b2103dbc6b88fb155193020187-dirty
(I can push a fork if that's easier to follow/review) in ❯ rgrep thorvg *
[snip]
lvgl/CMakeFiles/lvgl_thorvg.dir/DependInfo.cmake: "/home/arthur/local/lv_port_linux_frame_buffer/lvgl/src/libs/thorvg/tvgXmlParser.cpp" "lvgl/CMakeFiles/lvgl_thorvg.dir/src/libs/thorvg/tvgXmlParser.cpp.o" "gcc" "lvgl/CMakeFiles/lvgl_thorvg.dir/src/libs/thorvg/tvgXmlParser.cpp.o.d"
lvgl/CMakeFiles/lvgl_thorvg.dir/DependInfo.cmake: "/home/arthur/local/lv_port_linux_frame_buffer/lvgl/src/others/vg_lite_tvg/vg_lite_tvg.cpp" "lvgl/CMakeFiles/lvgl_thorvg.dir/src/others/vg_lite_tvg/vg_lite_tvg.cpp.o" "gcc" "lvgl/CMakeFiles/lvgl_thorvg.dir/src/others/vg_lite_tvg/vg_lite_tvg.cpp.o.d"
Makefile:# Target rules for targets named lvgl_thorvg
Makefile:lvgl_thorvg: cmake_check_build_system
Makefile: $(MAKE) $(MAKESILENT) -f CMakeFiles/Makefile2 lvgl_thorvg
Makefile:.PHONY : lvgl_thorvg
Makefile:lvgl_thorvg/fast:
Makefile: $(MAKE) $(MAKESILENT) -f lvgl/CMakeFiles/lvgl_thorvg.dir/build.make lvgl/CMakeFiles/lvgl_thorvg.dir/build
Makefile:.PHONY : lvgl_thorvg/fast
Makefile: @echo "... lvgl_thorvg"
❯ rgrep thorvg * | wc -l
1241
|
Looks like you need https://github.com/lvgl/lvgl/blob/master/env_support/cmake/custom.cmake#L47-L52 |
|
Interesting, in which file do I have to insert that ? |
|
It should be passed in from cmake. |
|
My build worked without that flag because I ran |
|
@liamHowatt that works ! I get to compile a Do you know how I can debug this ? @XuNeo thanks for the suggestion but that didn't filter out thorvg. But I learned that I can compile it with ninja instead of make... that's interesting. |
|
You may try |
|
Tried that, it didn't change the output. |
|
Hi @arthurlutz, I hope you are ok, Could you share with us the output of the |
|
|
The output appears to be from the SBC rather than the workstation. Is it possible? In any case, we can see that you have execution permissions. 😕 |
|
Yes, the |
|
Yes, I know that the |
|
I can confirm the |
|
I would like to try something. First of all I would like to know if you are using this Toolchain as cross-compiler: 4.9.4 linaro toolchain. Also, I would like to ask you if you can share with us a link of your repository with the changes you made so far in a branch. |
|
The shell on the target is missing some of the nice things that come with standard ".bashrc" configs. It seems that you cannot launch an executable without specifying the full path to the executable. I was able to reproduce the problem like so Try running the executable like this: |
|
@HanesSciarrone I can confirm I'm using that toolchain (at least I think I have configured it to use it, and the information from @liamHowatt I thought of that too, and had tried the full path. Same result. I'm really curious as to where this |
|
@arthurlutz is it a read-only filesystem? It's not uncommon to have most/all of the rootfs be read-only in embedded Linux. Try |
|
Parts of the file system are mounted as I have a number of binaries that I manage to copy to that device and execute without this problem (some compiled golang, but also some compiled rust and compiled C as mentioned at the beginning of the issue). |
|
@arthurlutz Please try running |
|
@liamHowatt unfortunately |
|
@arthurlutz Hmm, any chance |
At first I thought that message was coming from the shell saying the file doesn't exist, but I think it is coming from from the executable. See if you can get one of these on your target
|
|
Hi @liamHowatt I'm not sure if the gdb command will work if the executable doesn't have the debug symbols. And the |
|
Nope, sorry : Can I compile the binary with some debug prints ? |
|
It's tricky because the message being printed for no
Agreed @HanesSciarrone, I was thinking we could break at syscalls ( |
# mount -o remount,rw /
# mv lvgl /bin/
# /bin/lvgl
-sh: /bin/lvgl: not found
# echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/binOh, and here is some info about the shell : # which sh
/bin/sh
# file /bin/sh
/bin/sh: symbolic link to `busybox'
# file /bin/busybox
/bin/busybox: setuid ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
# busybox
BusyBox v1.18.3 (2016-09-05 12:26:14 CEST) multi-call binary.(this feels like an escape game 🤣, thanks for playing with me) |
|
Do me a favor and run (interested in the
It really does XD |
First of all great project, I'm quite new to the embedded graphics stack and this project compiles and works out of the box on my laptop so that's great and very promising.
Any chances of giving some indications on how to cross compile this for an arm device ?
My use case is the following : I want to try it out on an ereader that only has framebuffer : https://linux-sunxi.org/Bookeen_Cybook_Muse ... right now I can compile https://github.com/allepet/nolim-ebook-sdk for it but am not sure I can build upon that and would rather have a framework such as LVGL to build upon.
The text was updated successfully, but these errors were encountered: