On Tue, Feb 25, 2020 at 04:19:56AM -0500, Thomas Dickey wrote: > On Mon, Feb 24, 2020 at 08:28:03PM -0500, Thomas Dickey wrote: > > On Mon, Feb 24, 2020 at 06:35:16PM -0500, Thomas Dickey wrote: > > > On Mon, Feb 24, 2020 at 06:25:30PM -0500, Thomas Dickey wrote: > > > > On Tue, Feb 25, 2020 at 04:37:11AM +0900, Yasuhiro KIMURA wrote: > > > > > From: "O. Hartmann" <ohartmann_at_walstatt.org> > > > > > Subject: r358062(ncurses) breaks installed ports, howto check? > > > > > Date: Mon, 24 Feb 2020 20:19:59 +0100 > > > > > > > > > > > After r358062, many installed ports do not work anymore on several running systems (CURRENT). > > > > > > /usr/src/UPDATING states one should reinstall all ncurses depending ports, but no hint is > > > > > > given! Can someone mitigate this lack of information? Is there a simple way to check what > > > > > > ports installed on a system rely on ncurses provided by the system? > > > > > > > > > > Check thread starting with following message. > > > > > > > > > > https://lists.freebsd.org/pipermail/freebsd-ports/2020-February/117710.html > > > > > > > > That's a start, but it gives an overly-broad approach, saying that > > > > anything linked to the ncurses library has to be recompiled. > > > > > > > > The ABI change is just to the (upper-level) curses interface. > > > > Most of the programs you'll have in ports use the (lower-level) termcap > > > > or terminfo interfaces. > > > > > > > > For example gettext uses terminfo (not curses). > > > > > > > > Curses applications use initscr or newterm (nm helps). > > > > I have a script which uses nm to tell me which interface is used. > > > > > > > > Actually, in my own ports, I don't see any which would be affected, > > > > since all of the curses applications are the utilities for ncurses > > > > (or for my testing of ncurses). > > > > > > > > Here's an example of what it tells me > > > > (n5==ncurses5, tc=termcap, ti=terminfo): > > > > > > > > ti bison > > > > n5*+ti captoinfo > > > > n5*+ti captoinfo6 > > > > n5*+ti clear > > > > n5*+ti clear6 > > > > n5+tc ded > > > > n5+ti dialog4ports > > > > > > actually this one isn't one of mine (needs to be recompiled) > > > > > > But for the rest - recompiling would be a waste of time. > > > > ...that's just looking at /usr/local/bin. I see Millard's list > > includes /usr/local/lib. I have some of those: > > > > c3+tc libXvMCr600.so > > tc libedit.so > > tc libedit.so.0 > > ti libgettextsrc.so > > tc libreadline.so > > tc libslang.so > > ti libtextstyle.so > > c3+tc libvulkan_radeon.so > > > > that is, mesa-dri uses curses, but libedit and libreadline do not. > > > > I have llvm80, but that doesn't live in either of /usr/local/bin > > or /usr/local/lib. It's in its own directory (with a script in > > the former pointing there). It uses curses (and is not a quick > > recompile). > > now... I discussed this briefly with the developer on the 20th of January. > > ncurses can be configured/built to use the old binary interface (ABI 5), > but he ran into some problem doing that, and decided to use ABI 6. > > At the time, I had supposed that cost would be contained by the system > builders, not considering the impact on users rebuilding ports. > > Depending on where FreeBSD is along that path, it might be worth > revisiting, to see exactly why the build with ABI 5 did not work. > I think we should anyway move on on ABI 6, which is why I didn't insist on ABI 5 when I could not find the root cause of it not working. In the futur we will update ncurses on more regular basis, and ABI 6 is what everyone else is using so probably what is the most tested. if I understand correctly upstream build system, staying on ABI 5 disable many features that are available in ABI 6. For those interested my current plan with ncurses is the following for freebsd 13.0: - split terminfo from ncurses (like the upstream build system) so a futur change in high level ABI will impact less consumers - only keep the widechar version of ncurses in base - add the pkgconf file in base to ease the ports tree. Again for people who don't want to rebuild everything compat12x package has been created and can be used to have all binaries working. Best regards, Bapt
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC