Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 695936 - sys-devel/gdb-8.3*: tui/tui-win.o: undefined reference to symbol 'keypad'
Summary: sys-devel/gdb-8.3*: tui/tui-win.o: undefined reference to symbol 'keypad'
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: tinfo
  Show dependency tree
 
Reported: 2019-09-30 16:02 UTC by Victor Mataré
Modified: 2020-01-12 18:35 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gdb-8.3.1 build.log (build.log,303.50 KB, text/x-log)
2019-09-30 19:32 UTC, Victor Mataré
Details
gdb-8.3.1 config.log (config.log,33.26 KB, text/x-log)
2019-09-30 19:33 UTC, Victor Mataré
Details
emerge --info (emerge.info,7.20 KB, application/x-info)
2019-09-30 19:34 UTC, Victor Mataré
Details
make --trace output of failing part (make.trace,122.76 KB, text/plain)
2019-09-30 19:39 UTC, Victor Mataré
Details
gdb-8.3.1/gdb/config.log (config.log,336.13 KB, text/x-log)
2019-10-01 11:16 UTC, Victor Mataré
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Mataré 2019-09-30 16:02:11 UTC
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
Comment 1 Sergei Trofimovich gentoo-dev 2019-09-30 19:05:14 UTC
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.
Comment 2 Victor Mataré 2019-09-30 19:32:39 UTC
Created attachment 591446 [details]
gdb-8.3.1 build.log
Comment 3 Victor Mataré 2019-09-30 19:33:21 UTC
Created attachment 591448 [details]
gdb-8.3.1 config.log
Comment 4 Victor Mataré 2019-09-30 19:34:12 UTC
Created attachment 591450 [details]
emerge --info
Comment 5 Victor Mataré 2019-09-30 19:37:04 UTC
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.
Comment 6 Victor Mataré 2019-09-30 19:39:46 UTC
Created attachment 591452 [details]
make --trace output of failing part
Comment 7 Sergei Trofimovich gentoo-dev 2019-09-30 21:16:22 UTC
(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.
Comment 8 Larry the Git Cow gentoo-dev 2019-09-30 21:52:08 UTC
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(+)
Comment 9 Sergei Trofimovich gentoo-dev 2019-09-30 22:02:02 UTC
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?
Comment 10 Sergei Trofimovich gentoo-dev 2019-09-30 22:13:58 UTC
(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?
Comment 11 Victor Mataré 2019-10-01 10:29:11 UTC
That's right, I do have sys-libs/libtermcap-compat installed because it's required by some legacy out-of-tree programs.
Comment 12 Victor Mataré 2019-10-01 11:16:29 UTC
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.
Comment 13 Sergei Trofimovich gentoo-dev 2019-10-01 20:15:55 UTC
(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
Comment 14 Victor Mataré 2019-10-01 23:45:09 UTC
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...?
Comment 15 Sergei Trofimovich gentoo-dev 2019-10-02 07:22:05 UTC
(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.
Comment 16 Victor Mataré 2019-10-05 01:27:57 UTC
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!
Comment 17 Fat-Zer 2020-01-12 18:35:14 UTC
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*