Re: [Buildroot] [PATCH 1/1] package/pkg-utils.mk: fix per-package build with ncurses

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

On Sun, 29 Aug 2021 21:37:48 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Sorry, this is not the correct solution. Indeed, we can not accept that
> a package overwrites a file provided by another package. See the
> explanations Thomas and I discussed earlier today:
> 
>     https://lore.kernel.org/buildroot/20210829133955.74d921e9@windsurf/
>     https://lore.kernel.org/buildroot/20210829164031.GB1053080@scaer/
> 
> This case is however very special, and I have no idea (yet) on what the
> best solution is. I guess the curses headers in the toolchain are due to
> the presence of gdb with TUI support...

gdb with TUI support would mean to have ncurses (library and headers)
installed for the host, but here it's in the sysroot of the toolchain,
while for the target we only build gdbserver.

The two build failures that Fabrice is pointing to are RISC-V 64-bit,
and I believe until recently gdbserver was not available on RISC-V
64-bit. So it means that when we enable BR2_PACKAGE_GDB=y when building
our RISC-V 64-bit toolchains, instead of getting just the default of
gdbserver, we get the full gdb, which pulls in ncurses. This is clearly
a bug in the toolchain: we don't want to provide a full gdb for the
target.

Confirmed with:

$ tar tvf aarch64--glibc--bleeding-edge-2020.08-1.tar.bz2 | grep ncurses.h
lrwxrwxrwx root/root         0 2020-09-30 21:49 aarch64--glibc--bleeding-edge-2020.08-1/include/ncurses/ncurses.h -> curses.h

$ tar tvf riscv64--glibc--bleeding-edge-2020.08-1.tar.bz2 | grep ncurses.h
lrwxrwxrwx root/root         0 2020-10-01 10:22 riscv64--glibc--bleeding-edge-2020.08-1/riscv64-buildroot-linux-gnu/sysroot/usr/include/ncurses.h -> curses.h
lrwxrwxrwx root/root         0 2020-10-01 10:21 riscv64--glibc--bleeding-edge-2020.08-1/include/ncurses/ncurses.h -> curses.h

But in fact, I see we don't even provide gdbserver anywhere in fact,
since we're building the toolchain tarball with "make sdk", that
doesn't preserve the target directory. So we're building the target gdb
package for no reason...

Meh. Stuff to fix.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot