-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am Tue, 25 Feb 2020 05:02:54 -0500 Thomas Dickey <dickey_at_his.com> schrieb: > On Tue, Feb 25, 2020 at 10:27:37AM +0100, Baptiste Daroussin wrote: > > 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. > > yes... the wide-character configuration in ABI 6 adds a lot of stuff. > > ABI 5 is for compatibility; narrow-character applications (and termcap) > wouldn't benefit as much from 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 > > offhand, I see that 2/3 to 3/4 of the consumers use termcap or terminfo. > > My script tells me that - I've not integrated that into something that > would relate the results to packages, since I was mainly interested in > comparing curses/terminfo/termcap usage on a variety of systems. > > (I recall there's some problem using it with Solaris - when I revisit > that and get "enough" data, I'll probably make a nice table on a webpage). > > > - 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 > > > Thank you all very much for the fast response. I started sorting out the worts problems via "pkg check -B" which gave me some valuable hints. I decided to recompile all ports on those machines where we compile traditionally all ports. Kind regards, oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXlgoBQAKCRA4N1ZZPba5 Rx1LAQDwLuWTzNSLVAUhnZbpuzUxysTO/U7+vucSl5fiM5Ou3wD/RgkCbTZ699M+ g26HzGXU8v3yz2P043I7Gwi17JshmQY= =4A9a -----END PGP SIGNATURE-----Received on Thu Feb 27 2020 - 19:35:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC