|Summary:||dev-libs/libcec with sys-libs/ncurses[tinfo] - ld: CMakeFiles/cec-client.dir/curses/CursesControl.cpp.o: undefined reference to symbol 'keypad'|
|Product:||Gentoo Linux||Reporter:||Ettore Di Giacinto <mudler>|
|Component:||Current packages||Assignee:||Ian Whyman (thev00d00) <thev00d00>|
|Severity:||normal||CC:||candrews, esigra, Sergiy.Borodych|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Ettore Di Giacinto 2017-04-15 10:56:11 UTC
Bug to track the upstream PR progress Buildsystem misses libtinfo linking: [ 97%] Linking CXX executable cec-client /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -march=x86-64 -pipe -std=c++11 -lm CMakeFiles/cec-client.dir/cec-client.cpp.o CMakeFiles/cec-client.dir/curses/CursesControl.cpp.o -o cec-client-4.0.1 -rdynamic -L/usr/lib64 -lp8-platform -lpthread -lpthread -ldl -lcurses -lrt /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/cec-client.dir/curses/CursesControl.cpp.o: undefined reference to symbol 'keypad' /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line Opened already a PR upstream with the fix.
Comment 1 Jeroen Roovers 2017-04-15 12:13:48 UTC
Also note that the ebuilds state no dependency on sys-libs/ncurses to begin with.
Comment 2 Ian Whyman (thev00d00) 2017-05-12 21:52:24 UTC
Ive added the ncurses dep on the latest bump. The github patch makes it fail to build with -tinfo though
Comment 3 Ettore Di Giacinto 2017-05-14 12:14:10 UTC
Yes; From a quick look at their code and as per #457530, it seems tinfo should be mandatory as for now when ncurses is present ( https://github.com/Pulse-Eight/libcec/commit/5a19cd8ccd12810fcc9cd5dbf96aa57afe8c3e41 )
Comment 4 Ettore Di Giacinto 2017-09-03 09:49:50 UTC
Patch got included upstream
Comment 5 Mark Gomersbach 2018-01-10 18:49:59 UTC
(In reply to Ettore Di Giacinto from comment #4) > Patch got included upstream From the comment here it seems like a patch was tried locally and then latter it got accepted by upstream. But when I build now, the same thing still happens. Is there anything a non dev can do to make the patch from 3 months ago also end up in portage? I mean that in a literal sense, because I do not want volunteers to feel pressured. (thank you for your work btw). What could a mere user do? Make the ebuild (r1?) and attach it here?
Comment 6 Craig Andrews 2018-01-10 20:55:29 UTC
The best thing you could do is submit a pull request with the change, see https://wiki.gentoo.org/wiki/Gentoo_GitHub#How_to_make_a_pull_request If you use a proper commit message (see https://www.gentoo.org/glep/glep-0066.html#commit-messages ) it'll even automatically update this bug linking to the pull request. Then, it would be quite easy for us to review and merge the fix - thanks in advance!
Comment 7 Ian Whyman (thev00d00) 2018-01-13 10:42:22 UTC
Created attachment 514624 [details, diff] libcec-4.0.2-no-tinfo.patch Can you try this patch on a ncurses[tinfo] system?
Comment 8 Mark Gomersbach 2018-01-13 16:02:46 UTC
That works as well and is a better solution as it needs no ebuild voodoo.
Comment 9 Larry the Git Cow 2018-01-14 13:37:35 UTC
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=beda18baef91187b4c764e5c946ca3d965c36c6f commit beda18baef91187b4c764e5c946ca3d965c36c6f Author: Ian Whyman <email@example.com> AuthorDate: 2018-01-14 13:37:00 +0000 Commit: Ian Whyman <firstname.lastname@example.org> CommitDate: 2018-01-14 13:37:17 +0000 dev-libs/libcec: Fix build with ncurses[tinfo] Closes: https://bugs.gentoo.org/615634 Package-Manager: Portage-2.3.19, Repoman-2.3.6 dev-libs/libcec/files/libcec-4.0.2-no-tinfo.patch | 25 +++++++ dev-libs/libcec/libcec-4.0.2-r1.ebuild | 83 +++++++++++++++++++++++ 2 files changed, 108 insertions(+)