Bug 499837 - readline not properly linked against ncurses
readline not properly linked against ncurses
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: readline (Show other bugs)
5.3
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-08 10:18 EDT by Gordan Bobic
Modified: 2012-10-08 05:15 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-08 11:28:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordan Bobic 2009-05-08 10:18:46 EDT
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.
Comment 1 Miroslav Lichvar 2009-05-08 11:28:00 EDT
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.
Comment 2 Eero Tamminen 2010-04-25 06:01:15 EDT
(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!

Note You need to log in before you can comment on or make changes to this bug.