I don't know what triggers it, but on all my systems, gdb builds fail when linking the gdb binary: [...] CXXLD gdb /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: tui/tui-win.o: undefined reference to symbol 'keypad' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status [...] I have sys-libs/ncurses-6.1_p20190609[tinfo]. After some investigation I found that libtinfo is somehow missing from the linker command line. The Makefile has a variable TUI_LIBRARY which remains empty. Thus when I set it on the command line: MAKEOPTS='TUI_LIBRARY=-ltinfo' emerge gdb It builds successfully. Reproducible: Always
That does not happen for me. Please attach a few extra bits: 1. build.log 2. emerge --info 3. config.log files from a build tree I'll compare to the run on my system.
Created attachment 591446 [details] gdb-8.3.1 build.log
Created attachment 591448 [details] gdb-8.3.1 config.log
Created attachment 591450 [details] emerge --info
The build.log however isn't very useful I think, because all the compiler command lines are hidden. I could only get at the real command line by using make --trace in /var/tmp/portage/sys-devel/gdb-8.3.1/work/gdb-8.3.1.
Created attachment 591452 [details] make --trace output of failing part
(In reply to Victor Mataré from comment #5) > The build.log however isn't very useful I think It is still useful: most of configure output is there and USE flag sets are there. > because all the compiler command lines are hidden. I could only get at the real command line by using make --trace in /var/tmp/portage/sys-devel/gdb-8.3.1/work/gdb-8.3.1. That is a good point. Let's address it here as well.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bb6538b02a7df594bb1e91745f153944156492cc commit bb6538b02a7df594bb1e91745f153944156492cc Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-09-30 21:37:33 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-09-30 21:52:02 +0000 sys-devel/gdb: enable verbose gdb build, bug #695936 While tracing missing tinfo detection Victor noticed lack of precise arguments to gdb's linker and compiler commands. Two issues fixed here: - restore default V=1 build in custome Makefile snippet - set --disable-dependency-tracking to top-level ./configure to reach ./configure files that actually define it. Top-level does not and thus tricks portage's econf() into not passing it on. Reported-by: Victor Mataré Bug: https://bugs.gentoo.org/695936 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/gdb/files/gdb-8.3.1-verbose-build.patch | 13 +++++++++++++ sys-devel/gdb/gdb-8.3.1.ebuild | 9 +++++++++ sys-devel/gdb/gdb-9999.ebuild | 9 +++++++++ 3 files changed, 31 insertions(+)
Looking at build log delta on my system and yours' I see the following difference in gdb's detection: mine: checking for library containing tgetent... -ltinfow x86_64-pc-linux-gnu-g++ ... -o gdb ... -ltinfow -lncursesw ... your: checking for library containing tgetent... -ltermcap CXXLD gdb x86_64-pc-linux-gnu-g++ ... -ltermcap -lncursesw ... Thus on my system it works mostly by accident and we need to add an extra AC_CHECK_LIB call against keypad (if it's used directly by gdb). For completeness: Can you also attach gdb-8.3.1/gdb/config.log (not gdb-8.3.1/config.log) so I would check where the difference comes from?
(In reply to Sergei Trofimovich from comment #9) > Looking at build log delta on my system and yours' I see the following > difference in gdb's detection: > > mine: > checking for library containing tgetent... -ltinfow > x86_64-pc-linux-gnu-g++ ... -o gdb ... -ltinfow -lncursesw ... > > your: > checking for library containing tgetent... -ltermcap > CXXLD gdb > x86_64-pc-linux-gnu-g++ ... -ltermcap -lncursesw ... gdb/configure.ac detects tgetent as: # These are the libraries checked by Readline. AC_SEARCH_LIBS(tgetent, [termcap tinfow tinfo curses ncursesw ncurses]) I guess it happens because you happen to have libtermcap.so (or libtermcap.a) in your system and I don't. Which package provides it for you?
That's right, I do have sys-libs/libtermcap-compat installed because it's required by some legacy out-of-tree programs.
Created attachment 591500 [details] gdb-8.3.1/gdb/config.log config.log from /var/tmp/portage/sys-devel/gdb-8.3.1/work/gdb-8.3.1/gdb. Note however that this one is from a differen system than the files before. It's an Intel architecture (previous ones were AMD) and some (hopefully unrelated) USE flags are probably different. However the setup should be similar enough wrt. this bug, i.e. it has the same problem with libtermcap-compat and ncurses[tinfo] and the gdb build behaves the same.
(In reply to Victor Mataré from comment #11) > That's right, I do have sys-libs/libtermcap-compat installed because it's > required by some legacy out-of-tree programs. That can't be it as -ltermcap searches for unversioned library: libtermcap.so (or libtermcap.a). sys-libs/libtermcap-compat provides only versioned libraries libtermcap.so.2, libtermcap.so.2.0.8 and no headers. The idea is not to allow source-based software to discover those libraries while allowing binary-only software keep running. Your system seems to have libtermcap.so (or .a) file. I wonder where it comes from. qfile might be able to resolve it. Usage example: $ qfile /bin/bash app-shells/bash: /bin/bash
Yes, correct again. In fact I have a modified ebuild that adds the unversioned libtermcap.so symlink. At the time I thought nothing of it because it seems a perfectly normal thing to do. I did it because I had other software searching for an unversioned libtermcap.so. But thanks for the help in narrowing it down so quickly. My feeling is that relying on a non-existent unversioned symlink is a bit of a hackish way to differentiate between libtinfo and libtermcap (is that what is done?)... I can try and see if I can fix the other software, but right now I don't even remember what it was, so that will probably take some time. But as I said, there must be a cleaner solution than this...?
(In reply to Victor Mataré from comment #14) > Yes, correct again. In fact I have a modified ebuild that adds the > unversioned libtermcap.so symlink. At the time I thought nothing of it > because it seems a perfectly normal thing to do. I did it because I had > other software searching for an unversioned libtermcap.so. But thanks for > the help in narrowing it down so quickly. > > My feeling is that relying on a non-existent unversioned symlink is a bit of > a hackish way to differentiate between libtinfo and libtermcap (is that what > is done?)... gdb (and other software) has find exact provider of curses-like functions. There is no high-level way to do it other than trying to link to all candidate libraries in the system and see what works. Thus gdb does exactly that in the following order: gdb/configure.ac detects tgetent as: # These are the libraries checked by Readline. AC_SEARCH_LIBS(tgetent, [termcap tinfow tinfo curses ncursesw ncurses]) It's one of: - termcap - ncursesw+tinfow/ncurses+tinfo - curses - ncursesw/ncurses Normally the providers never come together in the system (except for w/non-w order) and order does not really matter as only on of the options is picked. Today's gentoo should always pick 'ncursesw+tinfow'. gdb happens to have termcap as a first entry and relies on readline's order (some old readline version). If readline happens to have other order, say AC_SEARCH_LIBS(tgetent, [tinfow tinfo curses ncursesw ncurses termcap]) it would cause even worse outcome: gdb would get the same tgetent symbol definition from very different implementations simultaneously: termcap and tinfo. That usually ends in SIGSEGVs like in bug #649704 (there collision was in ncurses+ncursesw). > I can try and see if I can fix the other software, but right now I don't > even remember what it was, so that will probably take some time. But as I > said, there must be a cleaner solution than this...? My worry is that your system now has a lot more packages linked into termcap (if they happen to try it first) or a mix of termcap/ncurses. That is not a stable system state and is hard to workaround in individual packages. If you have all the software installed via emerge it should already have an index of libtermcap users: $ fgrep libtinfo.so.6 $(portageq vdb_path)/*/*/NEEDED* Otherwise you can go through NEEDED sections of actual binaries/libraries with scanelf: $ scanelf -N libtinfo.so.5 /usr/bin /usr/lib64 You'll need to change libtinfo.so.5 to libtermcap.so (nothing should use it like that) and libtermcap.so.2 (typical SONAME linking). That way you will not find tools that do library loading at runtime but presumably they know how to fall back.
Alright, I found the culprit: http://www.clipsrules.net/AboutCLIPS.html Pretty stale piece of code, but still a very useful language. Anyways, patching the libtermcap dependency out of there and replacing it with libtinfo turned out surprisingly easy. Thanks again for the great help in narrowing this down!
I've run into the same issue. In my case the sys-libs/libtermcap-compat was required by dev-util/nvidia-cuda-toolkit. I also had the symlink '/usr/lib/libtermcap.so'. "equery b" reported it belong to sys-libs/libtermcap-compat. And it haven't been removed when remerging the package, I can't recall that I created it myself, so I assume it is a stale symlink from an older version. Just for the record the way to fix the issue: 1. rm /usr/lib/libtermcap.so 2. emerge -1 sys-libs/libtermcap-compat (just to be on the safe side) 3. rebuild all packages reported by fgrep libtermcap.so $(portageq vdb_path)/*/*/NEEDED*