[patch] fix build on systems with split ncurses/tinfo libraries

Forums:

Hi there,

On some systems, the ncurses library is split in two libraries: ncurses and tinfo. This makes moc fail to build since some of the symbols it thinks are in libncurses are in fact in libtinfo (e.g., cbreak).

This patch adds detection in m4/mp_with_curses.m4 for the missing cbreak symbol and tries to add -ltinfo to the required libraries if it is indeed missing.

Note that the code appropriately adds -ltinfo or -ltinfow depending on the selected ncurses library. I do not know whether the curses library is affected so I left it untouched.

Please review!

Thanks,
LaomaiWeng


diff -u a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in 2015-11-20 09:38:51
@@ -349,7 +349,7 @@
AC_DEFINE([HAVE_SET_ESCDELAY], 1, [Define if you have set_escdelay.]),
[AC_CHECK_FUNC([setenv], ,
AC_MSG_ERROR([Required function setenv not found.]))])
+ EXTRA_LIBS="$EXTRA_LIBS -l$CURSES_LIB $TINFO_LIBS"
- EXTRA_LIBS="$EXTRA_LIBS -l$CURSES_LIB"
fi

dnl popt
diff -u a/m4/mp_with_curses.m4 b/m4/mp_with_curses.m4
--- a/m4/mp_with_curses.m4
+++ b/m4/mp_with_curses.m4 2015-11-20 09:38:24
@@ -24,6 +24,7 @@
[Don't use ncursesw (UTF-8 support)])],,)

CURSES_LIB=""
+ TINFO_LIBS=""

if test "$with_ncursesw" != "no"
then
@@ -40,6 +41,11 @@
AC_DEFINE(HAVE_NCURSES_H, 1, [Define if you have ncursesw/curses.h])
AC_DEFINE(HAVE_NCURSESW, 1, [Define if you have libncursesw])
CURSES_LIB="ncursesw"
+ AC_CHECK_FUNC([cbreak],
+ [],
+ [AC_CHECK_LIB([tinfow], [cbreak],
+ [TINFO_LIBS="-ltinfow"],
+ [AC_MSG_ERROR([Required function cbreak not found.])])])
fi
fi

@@ -69,7 +75,13 @@
then
AC_DEFINE(HAVE_NCURSES_H, 1, [Define if you have ncurses.h])
CURSES_LIB="ncurses"
+ AC_CHECK_FUNC([cbreak],
+ [],
+ [AC_CHECK_LIB([tinfo], [cbreak],
+ [TINFO_LIBS="-ltinfo"],
+ [AC_MSG_ERROR([Required function cbreak not found.])])])
fi
fi
+
LIBS="$mp_save_LIBS"
])dnl


On some systems, the ncurses library is split in two libraries: ncurses and tinfo. This makes moc fail to build since some of the symbols it

On those systems which do, is ncurses also configured with --enable-pc-files?

If so, the Libs setting in the .pc file(s) include -ltinfo and pkg-config(1) would correctly pick it up. However, AX_WITH_CURSES does not use pkg-config(1), so we miss it.

I believe this fix is better directed upstream at the GNU AutoConf Archive's ax_with_curses.m4 maintainer so it will use pkg-config(1) if available and your solution if not. Then it will be of benefit to all ncurses-using applications.

On my system (Gentoo Linux), the .pc file is indeed installed and pkg-config correctly picks up the dependency on -ltinfo.

Thanks for directing me towards the GNU AutoConf Archive, I did not know about it. I will definitely submit my patch there. :)

I'm wondering if AX_WITH_CURSES is only intended for use when pkg-config isn't available. If that's the case and given that MOC requires pkg-config to build, then maybe it should switch to use PKG_CHECK_MODULES rather than AX_WITH_CURSES.

Of course, this requires any distribution having pkg-config (and therefore able to build MOC) to have also configured ncurses with --enable-pc-files. (It's a shame that ncurses does not default to installing .pc file(s) if pkg-config is available.)

So, some feedback, please:

  • Does anyone know of a distribution which has pkg-config and installs ncurses without .pc file(s)?
  • Does anyone have a good reason why MOC shouldn't ditch AX_WITH_CURSES in favour of PKG_CHECK_MODULES?

I made some changes to the Ncurses detection for the Tlf project recently and received a report of ncurses/panel.h not being found. I tested with PKG_CHECK_MODULES but that failed on the reported system and discovered there is no ncurses.pc (I looked at all the packages myself and never found that file). I wound up using AX_WITH_CURSES and AX_WITH_CURSES_EXTRA macros which seem to be working so far.

I'm actually looking at the moc source for tips on Alt key handling in Tlf when using keypad(). I'm browsing the forum and ran across this so thought I'd offer what I found in the past couple of weeks.

Thanks for that information. I guess it answers my two questions: there are distributions which do not install the .pc files and therefore I cannot use PKG_CHECK_MODULES.

So it looks like we're still reliant on an upstream fix for AX_WITH_CURSES. If that does not happen there is some Autoconf hackery to be done, but in the meantime using LDFLAGS with configure is a handy solution to add to your build recipe.

I just recently submitted a fix for AX_WITH_CURSES_EXTRA to the GitHub mirror of the project and it was pushed upstream. If the OP can reply whether a patch was submitted to the Autoconf Macro Archive, else I can push a patch on his behalf. Anything to nail down Ncurses detection a bit better will help my project as well.

I've updated the AX_WITH_CURSES macro in the autoconf macros archive. It now first tries to use pkg-config to find the required flags, and failing that, it switches to the old manual style of guessing flags. Could you try this and integrate it? It would make things a lot easier in Gentoo and the 99% of distributions providing ncurses .pc files, as the pkg-config part ensures it being forward compatible. Ultimately though, the goal should be to switch to PKG_CHECK_MODULES completely, and rather work with distributions to provide these files instead of using obscore and horrible autoconf macros to guess flags.

Excellent! Thank you for doing that. I shall test and integrate it.

I also completely agree with your comments regarding .pc files. It might be worth approaching the curses maintainer(s) to obsolete --enable-pc-files in favour of always installing them; it's hard to imagine any distribution not now using pkg-config.

I have now committed a patch (r2911/r2912) which integrates the changes made to AX_WITH_CURSES and which has been tested by the OP and, of course, the MOC Corporation QA Department.

It was reported by upstream that the ncurses maintainers were approached to make --enable-pc-files the default but they were unwilling to do so.