Description of problem: Linking against readline throws up missing symbols provided by ncurses. Adding linking against ncurses works as a workaround, but it shouldn't be required. Version-Release number of selected component (if applicable): readline-5.1-1.1 readline-devel-5.1-1.1 ncurses-5.5-24.20060715 ncurses-devel-5.5-24.20060715 How reproducible: 100% Steps to Reproduce: 1. Put this in a file, e.g. conftest.cc: <pre> #ifdef __cplusplus extern "C" void std::exit (int) throw (); using std::exit; #endif #ifdef __cplusplus extern "C" #endif char readline (); int main () { readline (); ; return 0; } </pre> 2. Compile with: g++ -o conftest -g -O2 conftest.cc -lreadline Actual results: /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `PC' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetflag' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetent' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `UP' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tputs' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgoto' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetnum' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `BC' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetstr' collect2: ld returned 1 exit status Expected results: Successful compilation. Additional info: The missing references seem to be from ncurses. Adding ncurses to the linker parameters works around the problem, but that indicates that the readline library wasn't linked properly. This compiles fine with the following: g++ -o conftest -g -O2 conftest.cc -lreadline -lncurses But the "-lncurses" shouldn't be required.
The problem is it can be linked with libtermcap or libncurses, they both provide similar API. Forcing libreadline to be linked with libncurses would possibly break applications linked with libtermcap. It's up to application to choose which library should be used, usually it's handled in configure scripts. In RHEL6 only terminfo will be supported, so readline is linked with libtinfo from ncurses package.
(In reply to comment #1) > The problem is it can be linked with libtermcap or libncurses, they both > provide similar API. Forcing libreadline to be linked with libncurses would > possibly break applications linked with libtermcap. Debian solved this problem already in the last century (archives went only to back 1997, so I don't know exactly when). As libncurses provides the libtermcap API, in Debian /usr/lib/libtermcap.so is just a symlink to /usr/lib/libncurses.so. So things built against both libtermcap and libncurses work just fine. Therefore this is only a problem for binary-only programs. But readline is GPL, so it cannot be used in binary-only programs and therefore those cannot (legally) have this issue. For binary-only programs that linked just libtermcap and needed its ABI, Debian had libtermcap-compat package which provided the (inferior) /etc/termcap terminal description database and ABI compatible /usr/lib/libtermcap.so.2 library. This package seems to have been dropped in Debian Etch (released 2007), so I guess all of these obsolete binary-only programs had been fixed by then. FYI: We just got a complaint from a user that our program doesn't work on RHEL5 (well, actually CentOS). Forcing our program to directly link something from which it depends only indirectly is clearly broken[1], so I don't think we're going to do that. Couldn't you just fix this brokenness? [1] Distros complain about that (I think Fedora included) and it would also cause the issue which you claim to be the reason why don't fix this bug!