[Bug 197317] Split libncurses into separate libncurses and libtinfo

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: vmagerya at 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.