Date: Wed, 04 Feb 2015 11:09:53 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 197317] Split libncurses into separate libncurses and libtinfo Message-ID: <bug-197317-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197317 Bug ID: 197317 Summary: Split libncurses into separate libncurses and libtinfo Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: vmagerya@gmail.com Some time ago I (and others as well) have encountered a problem with Python 'curses' module, the solution to which requires a modification to how we build ncurses in base. Here's the background of the problem. 1. Our build scripts for ncurses in base (see lib/ncurses and contrib/ncurses) produce one big library with all the curses functions, libncurses.so, and then symlinks smaller libraries like libtermcap.so and libtinfo.so to libncurses.so. They also produce a Unicode version of that library, libncursesw.so, with a corresponding set of symlinks. 2. Other libraries like libreadline.so (from devel/readline, but previously it was in the base as well), use the 'tgetent' family of functions contained in libtermcap (or libtinfo, which provides those functions as well). Since libtermcap.so is a symlink, libreadline.so gets linked to libncurses.so. 3. Python has a module 'readline' that uses libreadline.so, and another module 'curses' that uses the Unicode version of ncurses, libncursesw.so. Some programs may have both of these modules loaded, which leads to both libncurses.so (through libreadline) and libncursesw.so loaded into the same process. 4. Since both libncurses and libncursesw have identical set of functions, linking to them both may lead to problems. In fact, Python test suite was crashing due to this interaction; for this reason a workaround was added to Python build scripts that checked if libreadline.so is linked with libncurses.so, and if so, it would link Python's 'curses' module with libncurses.so, instead of libncursesw.so. This prevented crashing, but made displaying Unicode text via the 'curses' module impossible. See Python issue 7384 [1] for how this came to pass. Due to all of this, Python's 'curses' module does not display Unicode characters correctly on FreeBSD (see PR 171246 [2] for a test case). The fix for this problem is to split ncurses into separate libtinfo.so (not a symlink!) and libncurses.so, with the latter linking with the former. This is what the upstream ncurses does (also, devel/ncurses). This is also what most Linux distros do, and Python works well in this setup. Note that with this change libncurses.so will still provide the same set of functions, so no regression will occur. Unfortunately we don't use native ncurses build scripts in base, and I don't know how to modify our custom ones to this effect, which is why this PR is without a patch. So, if anyone knows a way to make our build scripts for ncurses to install a separate libtinfo.so, that would be very much appreciated. [1] http://bugs.python.org/issue7384 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171246 -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-197317-8>