This is true for the readline library, too. On a Fedora Core 1 system I experienced similar problems with linking against the readline library. The compiler does not complain but on runtime I get the error that the libreadline.so.4 could not be loaded due to a relocation error which comes due to a missing symbol: BC. This symbol is defined in the libncurses or in the libtermcap. So one of them should be in the requirements list for the libreadline.so.4. An `ldd libreadline.so.4` on for instance a Debian system brings up the following: libncurses.so.5 => /lib/libncurses.so.5 (0x40040000) libc.so.6 => /lib/tls/libc.so.6 (0x40080000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) The same on thing done on my Fedora Core 1 system delivers the following output: libc.so.6 => /lib/tls/libc.so.6 (0x0091e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00906000) Adding the -lncurses or -ltermcap option to the command line of gcc also helps but in my understanding this isn't the things should go.
I think it's up to the application to link to the right thing, not the library, in this instance -- especially since two libraries both provide the symbol in question.
But the application does not use the symbol directly. It just uses symbols provided by the readline library and this library itself then needs the symbol in question. So its in the responsibility of the library creator to assure that all dependend libraries get loaded when the library itself is used. Or should the application developer be required to firgure out when he wants to use this or that library which other libraries he also needs to get the one library he wants to use to work?