Version 19.1.0 - lldb fails to compile when using split ncurses and terminfo

[davide-q]

This started in RC1 and I was hoping to get it fixed before it was released.

The failure is about linking Curses-related objects, spitting out many errors like

 lib/liblldbCore.a(IOHandlerCursesGUI.cpp.o): undefined reference to symbol 'define_key@@@@NCURSES6_TINFO_5.0.19991023'
FAILED: lib/liblldb.so.19.1.0-rc1
IOHandlerCursesGUI.cpp:(.text._ZN6curses6Window12DrawTitleBoxEPKcS2_[_ZN6curses6Window12DrawTitleBoxEPKcS2_]+0x4a): undefined reference to `acs_map'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x112c): undefined reference to `curs_set'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1138): undefined reference to `stdscr'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1145): undefined reference to `keypad'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1be9): undefined reference to `define_key'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1bfa): undefined reference to `define_key'

and many, many more

I wonder if #25067 has been inadvertently re-introduced?

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (davide-q)

With various errors like

 lib/liblldbCore.a(IOHandlerCursesGUI.cpp.o): undefined reference to symbol 'define_key@@@@<!-- -->NCURSES6_TINFO_5.0.19991023'
FAILED: lib/liblldb.so.19.1.0-rc1
IOHandlerCursesGUI.cpp:(.text._ZN6curses6Window12DrawTitleBoxEPKcS2_[_ZN6curses6Window12DrawTitleBoxEPKcS2_]+0x4a): undefined reference to `acs_map'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x112c): undefined reference to `curs_set'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1138): undefined reference to `stdscr'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1145): undefined reference to `keypad'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1be9): undefined reference to `define_key'
ld: IOHandlerCursesGUI.cpp:(.text._ZN12lldb_private18IOHandlerCursesGUI8ActivateEv.part.713+0x1bfa): undefined reference to `define_key'

and more

I wonder if #25067 has been inadvertently re-introduced?

[davide-q]

Just FYI, in my environment the problem has not changed with rc2

[DavidSpickett]

I wonder if #25067 has been inadvertently re-introduced?

I think so.

The original terminfo fix from #69458 was removed by #92865 which removed terminfo as a dependency.

The original fix is mentioned in spack/spack#36954 where they are missing the same symbol you are.

And someone from there turned up on the removal PR: #92865 (comment)

Perhaps this is because on a system where ncurses and terminfo are combined, removing terminfo is ok because the symbols come from the combined ncurses anyway. When they are split into two, we still have to link terminfo as well to be able to use ncurses.

What is your environment and does it have this split? Some of the commands shown in #25067 (comment) can confirm that, I presume.

@JDevlieghere also commented there but didn't want to commit something without trying it, so if we can run your environment in a container we can figure it out.

[davide-q]

Thanks @DavidSpickett

My environment is a bare-metal RHEL 8.8 installation in which I am attempting (as I always have) a spack-based install of LLVM, so all of your sleuthing is spot-on! I don't use containers, so I can't help with that (unless I make a massive effort), but perhaps you would be able to reproduce the issue with spack which is a git-clone and a couple of spack bootstrap commands. Let me know if you would like me to list a step-by-step on how to reproduce it in that context.

[davide-q]

The llvm-19.1.0-rc3 version has still this issue (and a couple more, one of which is #106549 )

[davide-q]

Nothing has changed with RC4, I updated the name to reflect that.

I hope LLVM is not going to release 19.1 with this building bug.

[davide-q]

So disappointing to see the release happening despite this serious problem

[jryans]

LLVM releases follow a set schedule and do not generally wait for specific fixes.

I would think the quickest path here would be for someone with access to the environment in question to prepare a fix.