Apparent Broken Build

[rpe2101]

Build appears to be broken. I'm trying to duplicate your distributed kernel, and initrd for my new v1.2 board. I attempted to follow the README.md instructions on my x86 workstation. Problem appears to be something with termcap when building ncurses for buildroot. After trying a bunch of different things, I've started over and attempted to provide a clean log for this bug report.

First, my system is: $ neofetch --stdout

robert@OptiPlex-9020 OS: Ubuntu 23.04 x86_64 Host: OptiPlex 9020 00 Kernel: 6.2.0-24-generic Uptime: 19 hours, 22 mins Packages: 3215 (dpkg), 21 (snap) Shell: zsh 5.9 Resolution: 3840x2160 DE: GNOME 44.0 WM: Mutter WM Theme: Adwaita Theme: Yaru [GTK2/3] Icons: Yaru [GTK2/3] Terminal: tmux CPU: Intel i7-4770 (8) @ 3.900GHz GPU: Intel HD Graphics Memory: 3576MiB / 15882MiB

Commands followed: $ git clone --recursive https://github.com/starfive-tech/VisionFive2.git 1>status.log 2>&1

status.log reads: Cloning into 'VisionFive2'... Submodule 'buildroot' (https://github.com/starfive-tech/buildroot.git) registered for path 'buildroot' Submodule 'linux' (https://github.com/starfive-tech/linux.git) registered for path 'linux' Submodule 'opensbi' (https://github.com/starfive-tech/opensbi.git) registered for path 'opensbi' Submodule 'soft_3rdpart' (https://github.com/starfive-tech/soft_3rdpart.git) registered for path 'soft_3rdpart' Submodule 'u-boot' (https://github.com/starfive-tech/u-boot.git) registered for path 'u-boot' Cloning into '/home/robert/VisionFive2/buildroot'... Cloning into '/home/robert/VisionFive2/linux'... Cloning into '/home/robert/VisionFive2/opensbi'... Cloning into '/home/robert/VisionFive2/soft_3rdpart'... Cloning into '/home/robert/VisionFive2/u-boot'... Submodule path 'buildroot': checked out '9ff7877cafc0b2a9a0534ce49d5deed7b6b6458d' Submodule path 'linux': checked out '4964ce0a869e92df26331833894c9d0fd84d80f3' Submodule path 'opensbi': checked out 'c6a092cd80112529cb2e92e180767ff5341b22a3' Submodule path 'soft_3rdpart': checked out 'e2b76cd5733ce85d7145a6d71fb50a6218abed5c' Submodule path 'u-boot': checked out '62eeb016d65b6872408d9e5384cd9626aee8ff2a'

CD'd into the directory and running git status to show I'm on the correct branch $ git status On branch JH7110_VisionFive2_devel Your branch is up to date with 'origin/JH7110_VisionFive2_devel'.

And attempted to build. Attaching the failed build as status.log. Used this command to generate attachment: $ make -j 4 >> status.log 2>&1 status.log

I tried again and received a different but also broken result. I assume because of the j option kicking off other targets.: $ make -j 4 >> status2.log 2>&1 And had to split it to upload it $ split -n 2 status2.log status2.log status2aa.log status2ab.log

And tried again $ make -j 4 >> status3.log 2>&1 status3.log

And again $ make -j 4 >> status4.log 2>&1 status4.log

Until it is stuck $ make -j 4 >> status5.log 2>&1 status5.log

Could use some help. Thank you.

[rpe2101]

Additional persistence found a solution to this one error. I fixed the issue with tic by using my ubuntu working version of tic vs. the broken version built by buildroot. Here's the diff for VisionFive2/work/buildroot_initramfs/build/ncurses-6.1/misc/run_tic.sh:

53c53
< : ${TIC_PATH:=tic}
---
> : ${TIC_PATH:=/usr/bin/tic}

Not a true fix because for a resilient source package... buildroot's version needs to work. The next error with buildroot does not appear to be because of this change. Next error is with meson, Weston and Wayland. Why is Wayland required to build a initrd? Will attempt to gather appropriate information to try to inform of this issue.

[rpe2101]

Identified workaround for next problem:

diff on VisionFive2/work/buildroot_initramfs/host/bin/pkg-config new< >old

9c9
<       PKG_CONFIG_SYSROOT_DIR= \
---
>       PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR:-${DEFAULT_PKG_CONFIG_SYSROOT_DIR}} \

pkg-conf's pc file, VisionFive2/work/buildroot_initramfs/host/lib/pkgconfig/wayland-scanner.pc already stdout's a full pathname. Prepending it with SYSROOT gives an invalid path.

[andyhu-stf]

As far as I know, we have not compiled the whole SDK on Ubuntu 23.04 before. It is weird that the ncurses 6.1 build had error log tic: symbol lookup error: tic: undefined symbol: _nc_disable_period

Maybe we should upgrade the ncurses package in buildroot to fix it. Still we recommend that you should compile the SDK on Ubuntu 16 18 20 22

[rpe2101]

The tic issue is present with the upstream version of buildroot as well on my system, and the problem is agnostic to the ncurses version. It looks like gcc (Ubuntu 12.2.0-17ubuntu1) 12.2.0 has a different treatment of linker RPATHs than in the past. This is causing buildroot's tic (or any buildroot built host programs) to use the system's .so files. It looks like the gcc linker now by default takes the RPATH flag and puts it in as a RUNPATH flag, even though buildroot specifically asks to set the RPATH. You have to use a new linker flag to get gcc ld to use the RPATH as asked. This is "-Wl,--disable-new-dtags". The diff below looks to be the correct place to put the change in the buildroot folder:

diff --git a/package/Makefile.in b/package/Makefile.in
index 24089a4a..0dbfcdd8 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -242,7 +242,7 @@ HOST_CPPFLAGS  = -I$(HOST_DIR)/include
 HOST_CFLAGS   ?= -O2
 HOST_CFLAGS   += $(HOST_CPPFLAGS)
 HOST_CXXFLAGS += $(HOST_CFLAGS)
-HOST_LDFLAGS  += -L$(HOST_DIR)/lib -Wl,-rpath,$(HOST_DIR)/lib
+HOST_LDFLAGS  += -L$(HOST_DIR)/lib -Wl,-rpath,$(HOST_DIR)/lib -Wl,--disable-new-dtags

 # host-intltool should be executed with the system perl, so we save
 # the path to the system perl, before a host-perl built by Buildroot

[rpe2101]

Was able to get the entire system built on Ubuntu 23.04. I have tested the kernel and initrd files, and have verified they completely boot up on my VisionFive2 board. The earlier comments about changing PKG_CONFIG_SYSROOT_DIR was not the correct resolution path. Resolving this with the approach I describe below did.

First the problem: Meson build system packages that need wayland-scanner fail to find it. They fail because the wayland.pc file used to find it gives a full path, but the host-pkgconf wrapper tries to also prepend systemroot_dir giving an invalid path. Messing with the host/bin/pkg-config as I mentioned above is not the correct solution because other packages in buildroot depend upon sysroot being set. I found plenty of forum conversation about the critical parts of meson code with respect to wayland-scanner. The key part is in the meson.build files of the individual packages needing wayland-scanner.

The link here has a recommended solution that works (for me anyway). https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/157 . Basically in each meson.build file that fails you find this line: prog_scanner = find_program(dep_scanner.get_pkgconfig_variable('wayland_scanner'))

And you make it read : prog_scanner = find_program('wayland-scanner')

This works because meson tries to find wayland-scanner in the path vs. using a pkg-config script. This works well because buildroot has already set the path to favor the buildroot built host executables, of which wayland-scanner is one of.

I also found several instances in the main project Makefile where the buildroot output folders' Makefile were being used in lieu of the buildroot source directory's Makefile. The build fails because the output directory Makefile doesn't have all the make targets. Diff below:

diff --git a/Makefile b/Makefile
index b9aa6f0..d2d6407 100644
--- a/Makefile
+++ b/Makefile
@@ -164,8 +164,8 @@ $(buildroot_initramfs_tar): $(buildroot_srcdir) $(buildroot_initramfs_wrkdir)/.c

 .PHONY: buildroot_initramfs-menuconfig
 buildroot_initramfs-menuconfig: $(buildroot_initramfs_wrkdir)/.config $(buildroot_srcdir)
-   $(MAKE) -C $(dir $<) O=$(buildroot_initramfs_wrkdir) menuconfig
-   $(MAKE) -C $(dir $<) O=$(buildroot_initramfs_wrkdir) savedefconfig
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) menuconfig
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) savedefconfig
    cp $(dir $<)defconfig $(buildroot_initramfs_config)

 # use buildroot_initramfs toolchain
@@ -225,11 +225,11 @@ $(vmlinux): $(linux_srcdir) $(linux_wrkdir)/.config $(target_gcc)
        modules_install

 vpudriver-build: $(vmlinux)
-   $(MAKE) -C $(buildroot_initramfs_wrkdir) O=$(buildroot_initramfs_wrkdir) \
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) \
        INSTALL_MOD_PATH=$(module_install_path) wave511driver
-   $(MAKE) -C $(buildroot_initramfs_wrkdir) O=$(buildroot_initramfs_wrkdir) \
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) \
        INSTALL_MOD_PATH=$(module_install_path) wave420ldriver
-   $(MAKE) -C $(buildroot_initramfs_wrkdir) O=$(buildroot_initramfs_wrkdir) \
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) \
        INSTALL_MOD_PATH=$(module_install_path) codaj12driver

 linux-tools-build: $(vmlinux)
@@ -537,4 +537,4 @@ format-demo-image: format-boot-loader
        sudo tar -Jxvf $(DEMO_IMAGE)
    sudo umount tmp-mnt

--include $(initramfs).d
+#-include $(initramfs).d

[andyhu-stf]

there is no difference with below:

-   $(MAKE) -C $(dir $<) O=$(buildroot_initramfs_wrkdir) menuconfig
-   $(MAKE) -C $(dir $<) O=$(buildroot_initramfs_wrkdir) savedefconfig
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) menuconfig
+   $(MAKE) -C $(buildroot_srcdir) O=$(buildroot_initramfs_wrkdir) savedefconfig

In work/buildroot-initramfs/Makefile, there is: MAKEARGS := -C /space/code/freelight-u-sdk_6.1/buildroot

[andyhu-stf]

@rpe2101 thanks for your test report on ubuntu23.04.

I just had built the whole SDK on docker ubuntu23.04 environment. The building are ok. Maybe you have changed some package on your ubuntu23.04.

[sbates130272]

@rpe2101 thanks for all the hard work. Any chance you can create a fork and a branch with your changes in it so we can take a look? I can then use that to work on #50.

[sbates130272]

@andyhu-stf can you either push a branch or add a gist for the Dockerfile you used for 23.04? I can use that as a template for #50. Thanks!

[rpe2101]

I started over from a clean source tree again to be able to generate a clean diff. It built without issue. Amazed, I thought that I may have inadvertently polluted my workstation's environment into working. To verify, I started from a clean Ubuntu 23.04 docker. The clean source tree built again in Ubuntu 23.04 without issue.

¯\_(ツ)_/¯

[ThomasKorimort]

I did a build of StarFive v3.1.5 Software tree on the VisionFive 2 itself with the default checkout release tag or whatever according to the instruction at https://rvspace.org/en/project/VisionFive2_Debian_User_Guide section 4.6 and i ended up with a completely broken kernel, which would produce so many failures during boot, that it would stop in the middle of the boot procedure even without Ethernet networking functioning...