irqbalance fails to build: When the ui is disabled and ncurse is not installed and crosscompiling
Closed this issue · 3 comments
When configured with
./configure --host=arm-linux-gnueabihf --without-irqbalance-ui --prefix=<prefix>
the error
libtool: link: arm-linux-gnueabihf-gcc -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -g -O2 -o irqbalance activate.o bitmap.o classify.o cputree.o irqbalance.o irqlist.o numa.o placement.o procinterrupts.o -lglib-2.0 -lm -lncursesw -ltinfo -pthread
<crosscompliedir>arm-linux-gnueabihf/bin/ld: cannot find -lncursesw
<crosscompliedir>arm-linux-gnueabihf/bin/ld: cannot find -ltinfo
the cause (or at least suspected)
A couple of things, the sdk I'm using does not have suitable pkf-config
checking for arm-linux-gnueabihf-pkg-config... no
and it finds my host curses
checking for NCURSESW... yes
In configure.ac, there is a check for curses, and check for the UI. However the checks are separate and independent.
Solution
Wrap the config for curses, in the UI check
[AS_HELP_STRING([--without-irqbalance-ui],
[Dont build the irqbalance ui component])],
[with_irqbalanceui=$withval], [with_irqbalanceui=yes])
+#AS_IF(
+# [test "x$with_irqbalanceui" = "xyes"], [
+# AC_DEFINE([HAVE_IRQBALANCEUI], 1, [Build irqbalance ui component.])
+#])
+#AM_CONDITIONAL([IRQBALANCEUI], [test x$with_irqbalanceui = xyes])
AS_IF(
[test "x$with_irqbalanceui" = "xyes"], [
AC_DEFINE([HAVE_IRQBALANCEUI], 1, [Build irqbalance ui component.])
+ PKG_CHECK_MODULES([NCURSESW], [ncursesw], [has_ncursesw=yes], [AC_CHECK_LIB(curses, mvprintw)])
+ AS_IF([test "x$has_ncursesw" = "xyes"], [
+ AC_SUBST([NCURSESW_CFLAGS])
+ AC_SUBST([NCURSESW_LIBS])
+ LIBS="$LIBS $NCURSESW_LIBS"
+ AC_SUBST([LIBS])
+ ])
])
AM_CONDITIONAL([IRQBALANCEUI], [test x$with_irqbalanceui = xyes])
Take the above with a grain of salt, as I don't have much experience with autoconfig.
I'm not sure I would see this as a bug.
You indicate you don't have a suitable pkg-config, but it seems you have a pkg-config utility (or the error would have been that pkg-config wasn't found). What makes your pkg-config utility unsuitable? and wouldn't the fix then be to add the approriate pkg-config files to make it suitable?
As for your proposed fix, thats not going to cover it. pkg-config is used to find lots of dependent libraries (libnuma, glib2, ncurses, libnl3, systemd and libcap). Your change would have to be applied to all of those ,which doesn't seem feasible. But your pkg-config utility does find at least some of those packages (glib2 for instance is always required, and you didn't hit an error on that).
So it seems to me something is wrong with one of your installed pkg-config files (most likely libdir isn't specified for ncurses or some such, leading to -lncurses being called but no -L/path/to/ncurses/lib/dir).
Fair enough.
I'm cross-compiling for an embedded host. I have essentially two set of libraries and tools. The sdk for cross-compiling does not provide the pkf-config.
pkg-config is used to find lots of dependent libraries (libnuma, glib2, ncurses, libnl3, systemd and libcap)
--disable-thermal
will turn off looking for libnl3 (and not being an x86 system)- '--disable-numa` will turn off libnuma
--without-systemd
will turn off systemd checking--without_libcap_ng
will turn off libcap-ng
I would have expected to disable the UI would have disabled any dependencies that relied on the ui solely.
My next step, after reporting this bug was to crosscompile glib2. Whoever looking at it's install size it's to large for my application.
Thanks for your prompt response.
Thats a fair statement, I thought we had a need for ncurses outside of the ui, but looking now, thats not the case. If you want to consider a PR for that, I'd be willing to take it.
As for your cross compiling needs, thats a bigger issue. Cross compiles often need two separate system trees effectively, which is a pain in the rear to maintain. I've found its commonly easier to do cross compiles using containers.
I keep a set of cross-compile containers here:
https://github.com/nhorman/buildcontainers
And I believe armv4-gnueabihf is one of the available targets. You could easily build those, extend them with the libraries you need, and then build in them by using docker/podman run -V /path/to/your/src/tree:/work -w /work to build in them
The trick is getting your dependencies built. Frequently distro-produced pacakges (for things like glib2 forget to include the pkg-config files in their -dev subpackages, and you have to do some manual fixups)
If size is a concern for you here, you might consider building statically and stripping the resultant binary. Not sure if irqbalance is fully setup for that, but it shouldn't be too hard to get there