chunkeey:

This seems related to this gentoo bug https://bugs.gentoo.org/457530

with the information at hand I found this "lovely" commit in linux 4:

Meelis Roos reported a {menu,n}config regression:
 "I have libncurses devel package installed in the default system
  location (as do 99%+ on actual developers probably) and in this
  case, pkg-config is useless.  pkg-config is needed only when
  libraries and headers are installed in non-default locations but
  it is bad to require installation of pkg-config on all the machines
  where make menuconfig would be possibly run."

For {menu,n}config, do not use pkg-config if it is not installed.
For {g,x}config, keep checking pkg-config since we really rely on it
for finding the installation paths of the required packages.

So, in order to get this fixed, you need to take this up with
Masahiro Yamada yamada.masahiro@socionext.com. Write him a
mail and tell him about gentoo and mention the bug so he can
see that pkg-config is needed for menuconfig.

Pilatus:

Looking into it, this is not an upstream issue. It's a toolchain bug, and there seem to be two related issues at play.

• make menuconfig in the kernel calls the makefile in scripts/kconf, which ends up calling pkg-config. When invoked through OpenWRT buildroot that is pkg-config //of the toolchain//, i.e.openwrt/staging_dir/host/bin/pkg-config. That command fails because it requires an environment variable $STAGING_PREFIX, which is not defined. The closest is $STAGING_DIR_HOST. There are a few fallbacks in the kernel for when pkg-config fails, but none apply here.
• scripts/kconf requires that ncurses be installed. The toolchain is missing ncurses.

I haven't looked deeply enough yet to write a patch, but comment #1 is off the mark. The Gentoo bug is unrelated, and the kernel commit did not introduce a bug.

ynezz:

Can you please attach build.log.gz from the following command:

Pilatus:

Please find build log here

Pilatus:

I could get the kconfig script to link by defining export STAGING_PREFIX=$(STAGING_DIR_HOST) in target/linux/Makefile and adding a tools/ncurses package, but is that the kosher way to do things when cross-compiling?

In the compile stage we see both the host's and the toolchain's include files read (-I/home/ta/openwrt/staging_dir/host/include -I/usr/include/ncursesw) but the configure script is linked only against the toolchain (-L/home/ta/openwrt/staging_dir/host/lib). Could this be a kernel issue after all?

ynezz:

export STAGING_PREFIX=$(STAGING_DIR_HOST)

This is wrong as already explained in the email, this should be set properly already.

-L/home/ta/openwrt/staging_dir/host/lib

Why does it matter at all? Do you've any libncursesw in there?

scripts/kconfig/lxdialog/checklist.o: undefined reference to symbol 'keypad'
/lib64/libtinfow.so.6: error adding symbols: DSO missing from command line

objdump -T /lib64/libtinfow.so.6 | grep keypad

Could this be a kernel issue after all?

Or something with your system, who knows.

-DNCURSES_WIDECHAR=1

Maybe it's related to this?

Pilatus:

export STAGING_PREFIX=$(STAGING_DIR_HOST)
This is wrong as already explained in the email, this should be set properly already.

But it isn't set. In a clean OpenWRT install, when the target/linux/Makefile is reached, STAGING_PREFIX isn't set.

$ objdump -T /lib64/libtinfow.so.6 | grep keypad
0000000000013d70 g DF .text 0000000000000026 Base keypad
0000000000013ce0 g DF .text 0000000000000083 Base _nc_keypad

ynezz:

But it isn't set. In a clean OpenWRT install, when the target/linux/Makefile is reached, STAGING_PREFIX isn't set.

But why do you want it to be set? kernel_menuconfig target should be using your host compiler, includes and libraries, it shouldn't use the ones from OpenWrt, so you don't need those. Apparently kernel is using your host pkg-config, because it can find ncursesw correctly.

./staging_dir/host/bin/pkg-config.real --list-all | grep curses

What does it return for you?

0000000000013d70 g DF .text 0000000000000026 Base keypad

Ok, so then your host linker has some issues.

Pilatus:

It's not the host linker but the OpenWRT-supplied pkg-config wrapper.

The pkg-config wrapper invokes pkg-config.real like so: pkg-config.real --define-variable=prefix= --define-variable=exec_prefix= --define-variable=bindir=/bin --libs ncursesw and since --define-variable fails (because $STAGING_PREFIX is not set), it returns an empty value, and the fallback values in the kernel config script are applied but those are off and the linking fails.

When I used the host's pkg-config, kernel_menuconfig worked fine.

$ pkg-config --libs ncursesw
-lncursesw -ltinfow
$ ./staging_dir/host/bin/pkg-config.real --define-variable=prefix= --define-variable=exec_prefix= --define-variable=bindir=/bin --libs ncursesw
--define-variable argument does not have a value for the variable

ynezz:

Ok, so this is 4.14 which has broken pkg-config usage and it was fixed upstream in commits 1c5af5cf9308fff327f52c7efd2dfa732d370871 and fd65465b7016dc6d9fa5c2f39cc706c231c9a089 so 4.19 should work much better. So in order to fix it properly, you probably need to backport this patches or provide similar workaround to fix pkg-config usage within 4.14 kernel.

Pilatus:

Toolchain bug, not a kernel issue. See comment.

Pilatus:

Please find attached build log for 4.19 kernel. Also find attached build logs for 4.19 and 4.14 kernels with staging_dir/host/bin/pkg-config renamed to something else so that the kconfig script cannot find it and is forced to use the built-in ncurses detection logic.

When OpenWRT's pkg-config is missing kernel_menuconfig works just fine, when it's there it fails to build.

Please see comment from 09.08.2019 03:01. It's clear now that there is a problem with OpenWRT's pkg-config, in particular with the wrapper script.

Pilatus:

Attached is a build log with invocations of host pkg-config and the value of STAGING_PREFIX interspersed. All is fine, except for the targets in target/linux, where STAGING_PREFIX is undefined, and as a result, pkg-config fails and returns the empty string.

For the kernel_menuconfig target you'd like to invoke the system's pkg-config instead. What is the correct thing to do? I'd suggest to check for undefined STAGING_PREFIX and when it is undefined, call /usr/bin/pkgconfig instead, so that the kernel config script can find ncurses on the host. Suggestion for a patch is attached.

(Some Linux distributions split ncurses and tinfo. For those that don't, the present setup works fine, I believe.)

ynezz:

when it is undefined, call /usr/bin/pkgconfig instead, so that the kernel config script can

No, this is wrong approach, don't try to hardcode the /usr/bin path, this is not portable.

For those that don't, the present setup works fine, I believe

It works for me here on Ubuntu 18.04.2 LTS:

ldd /lib/x86_64-linux-gnu/libncurses.so.5 | grep tinfo
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f6ce5f76000)


and on Debian GNU/Linux 10 (buster) as well:

ldd /lib/x86_64-linux-gnu/libncurses.so.5 | grep tinfo
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f25b22a3000)


with the following linker command:

so as you can see, -lncurses is enough, no need to explicitly set -ltinfo as the linker is able to solve this dependency properly by itself.

Pilatus:

For portability we can save the location of system pkg-config early on, please see attached patch.

It works for me here on Ubuntu 18.04.2 LTS ... with the following linker command:
gcc -o scripts/kconfig/mconf scripts/kconfig/mconf.o scripts/kconfig/zconf.tab.o scripts/kconfig/lxdialog/checklist.o scripts/kconfig/lxdialog/inputbox.o scripts/kconfig/lxdialog/menubox.o scripts/kconfig/lxdialog/textbox.o scripts/kconfig/lxdialog/util.o scripts/kconfig/lxdialog/yesno.o -lncurses

That's because Ubuntu has a linker file that pulls in libtinfo:
$ cat /usr/lib/x86_64-linux-gnu/libncurses.so
INPUT(libncurses.so.5 -ltinfo)
You can't rely on its being present in all distributions.

For portability it's best to rely on the output of pkg-config, which insists on linking against libtinfo.
$ pkg-config --libs ncurses
-lncurses -ltinfo

ynezz:

For portability we can save the location of system pkg-config early on, please see attached patch.

Good, this looks better and might be acceptable, so please send the patch for the review https://openwrt.org/submitting-patches