The newly introduced USE=tinfo in sys-libs/nurses forces some symbols from libncurses.so to be moved to libtinfo.so. This means, your package needs to be linked in some situations against -lncurses -ltinfo (ncurses[tinfo]) instead of -lnurses (ncurses[-tinfo]). Luckily there is a simple solution: Use pkg-config. The ncurses package provides a .pc file, so the fixes should be straight forward with homebrewn as well as autotools, cmake and other buildsystems.
Adding a few in one go, I hope they are correct; if not, feel free to correct...
(In reply to comment #0) > The newly introduced USE=tinfo in sys-libs/nurses forces some symbols from > libncurses.so to be moved to libtinfo.so. > > This means, your package needs to be linked in some situations against > -lncurses -ltinfo (ncurses[tinfo]) instead of -lnurses (ncurses[-tinfo]). > > Luckily there is a simple solution: Use pkg-config. Sorry, I dont get it. What I as a user have to do to emerge broken packages (zsh, to be specific)?
Don't know if this should be reported here, in a separate bug report or even at all, but this bug also seems to affect media-gfx/jp2a. Build does *not* fail however, merely prints a warning, but ncurses-related options are missing from the resulting binary. Adding -ltinfo fixes the issue.
(In reply to comment #3) > Don't know if this should be reported here, in a separate bug report or even > at all, but this bug also seems to affect media-gfx/jp2a. > Build does *not* fail however, merely prints a warning, but ncurses-related > options are missing from the resulting binary. Adding -ltinfo fixes the > issue. Never in the Tracker itself, always in a new bug
(In reply to comment #2) as a normal user, you shouldn't be setting USE=tinfo in the first place
(In reply to comment #5) > (In reply to comment #2) > > as a normal user, you shouldn't be setting USE=tinfo in the first place dev-util/nvidia-cuda-toolkit requires that.
In case anyone needs a hotfix, just add /lib/libtinfo.so.5 to GROUP statement in /usr/lib/libncurses.so ld script (and similarly for libncursesw). Not very clean, but works for me so far for all affected packages.
Created attachment 382428 [details, diff] Fix configure.ac to use pkg-config v2 Sorry, this is corrected version. I forgot to remove function argument.
Oh hell. Wrong bug. Sorry guys.
Please add #508404 as "Depends On"
It's not as simple as switching pkg-config, as some packages simply need tinfo which was previously built into libncurses and now is not. Crudely linking against both isn't necessary for those cases.
If they only need tinfo, and they are using autotools you can use AC_SEARCH_LIBS([cbreak], [tinfo ncurses])
Request importance upgrade from "normal" to "blocking". I have lived with this bug for a year now, now it has completely compromised my system preventing emerge updates, must be fixed urgently.
This bug affects me also on amd64. I cannot emerge util-linux because of complaints about missing TERM_* variables when ncurses is compiled with tinfo (which I thought I needed because of nvidia-cuda-toolkit). Here's an example from compiling util-linux-2.25.2-r2 with ncurses built with tinfo: /var/tmp/portage/sys-apps/util-linux-2.25.2-r2/work/util-linux-2.25.2/text-utils/more.c:1816:34: error: 'TERM_HARD_COPY' undeclared (first use in this function) if ((Lpp <= 0) || my_tgetflag(TERM_HARD_COPY)) { ^ /var/tmp/portage/sys-apps/util-linux-2.25.2-r2/work/util-linux-2.25.2/text-utils/more.c:1821:20: error: 'TERM_EAT_NEW_LINE' undeclared (first use in this function) if (my_tgetflag(TERM_EAT_NEW_LINE)) ^ /var/tmp/portage/sys-apps/util-linux-2.25.2-r2/work/util-linux-2.25.2/text-utils/more.c:1827:23: error: 'TERM_AUTO_RIGHT_MARGIN' undeclared (first use in this function) Wrap = my_tgetflag(TERM_AUTO_RIGHT_MARGIN);
(In reply to Jacob Martin from comment #14) this is a tracker bug, not for reporting specific issues. please create dedicated bugs instead.
Created attachment 406220 [details, diff] ncurses-5.9-r3.ebuild.patch Can't the ncurses package install a full libncurses.so along with libtinfo.so? I've patched the ebuild to do that by compiling twice and installing only the libtinfo libraries and .pc files from the one compiled with tinfo. The advantages are that all packages compile fine, and even if a package uses -lcurses and -ltinfo as long as -lcurses comes first it should only link against libcurses (one less library to load for most packages). The main disadvantage is the longer compile times but it's not too bad (on a slow laptop a multilib build went from 16 to 22 mins).
*** Bug 570284 has been marked as a duplicate of this bug. ***
A significant issue caused by the historically bad decision of ncurses upstream is to make pkg-config file installation optional. This means that autoconf consumers of ncurses cannot unconditionally rely on their presence, which means that developers in practice eschew relying solely on PKG_CHECK_MODULES() for finding ncurses, see: https://moc.daper.net/node/1469 https://github.com/nzbget/nzbget/issues/188#issuecomment-198973436 I've raised this issue with upstream (https://lists.gnu.org/archive/html/bug-ncurses/2016-03/msg00011.html), but even if they decide to make .pc files non-optional, it will take years for this change to trickle down to 99% of users. So in the meantime, I've taken to fixing the AX_WITH_CURSES macro (https://github.com/peti/autoconf-archive/pull/69). It now first tries to use the pkg-config file to detect the proper flags (therefore being forward-compatible with future linkage changes), but will fall back to detecting the flags itself (including -ltinfo{,w} in ncurses 6). This should please upstream developers and Gentoo alike, as we can get pkg-config support and upstream does not have to solely rely on pkg-config. Does this sound like a tenable plan?
*** Bug 601764 has been marked as a duplicate of this bug. ***
My bug report has just been marked duplicate of this: https://bugs.gentoo.org/show_bug.cgi?id=601764 I don't want to just let it become buried so I'll make a reply here: Relying on pkg-config as a dynamic solution is good enough for finding the actual libraries to link against to during link-time, whether sys-libs/ncurses is enabled with tinfo or not. It's more accurate than just having 'export LDFLAGS="-ltinfo ${LDFLAGS}" LIBS="-ltinfo ${LIBS}"', although more complicated and requires more work[arounds]. But, that doesn't make other packages built against libncurses to automatically compile against libtinfo when sys-libs/ncurses[-tinfo] suddenly changes to sys-libs/ncurses[tinfo], or vice-versa. This would cause breakage unless revdep-rebuild is called. But not all people would want to always have that workaround solution. It would be better if rebuilding of packages would automatically be called during `emerge`, and that would make things _consistent_, and _synchronized_. That could also avoid possible build-time errors with build tools relying on libtinfo during a world update. Apply sys-libs/ncurses[tinfo=] to packages, and that would reduce the tinfo-related breakage reports.
(In reply to konsolebox from comment #20) this bug is a tracker, not for discussion. keep your thoughts in the other bug.
I'm not sure if there is a simple way to check the names of the dependant bugs, but looking through the opened ones I don't see any dev-libs/libcec.
For applications which only make curses calls (such as curs_set(3)), is the expectation that they now need to explicity link against tinfo as well?
i would like to add neomutt to the list https://github.com/neomutt/neomutt/issues/1118
Posted this in the forums, and was told to come here. :) This is from a failed compile of net-misc/cgminer-4.10.0 -ldl -lcurl -ljansson -lpthread -lusb-1.0 -lrt -lm lib/libgnu.a ccan/libccan.a -lncurses -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: cgminer-cgminer.o: undefined reference to symbol 'halfdelay' /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
(In reply to ta2002 from comment #25) No talking here. If you wish to make a report, please create a new bug and make it block this one.
Same issue on my setup https://gist.github.com/Kreyren/bc220910b26c07d4025d54a1de3c5eba Some warning about Bug #457530 should be probably in place.
