FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On Sun, 13 Jul 2003 11:44:48 -0700, "Steve Murphree" <smurph AT smcomp.com>
wrote:
> > On Sun, 13 Jul 2003 01:11:04 -0700, "Steve Murphree" wrote:
> > >
> > > Configure needs to do more checking for readline dependencies
>
> We should test for the readline library, then test for the library that
> has tputs() in it and also include it.  I'm not sure why libreadline
> links without those dependencies but I know it happens.  Supplying the
> curses library sometimes fixes the problem because it may have run-time
> information to link the termcap library.  If niether the curses library
> nor the readline library have this information, you get Chase's problem.
>  Look through the
> autoconf stuff from other applications that use readline.  You will see
> that everyone goes through some sort of song and dance to get readline
> to link.

I'll do some more checking.  Below is the configure.in test for readline. 
Freddy added it a year ago, and I imagine he found it elsewhere.  I'm not
sure what to change; afaict we're doing as you suggest, unless tputs(3) is
intrinsically different from tgetent(3).  

dnl readline test
dnl Readline is needed by the tty session. Set up a special RL_LIBS
dnl substitution for it.
OLDLIBS="$LIBS"
dnl Readline is linked with curses, and on some systems termcap must be
dnl linked in. Others (inc debian) have termcap built into ncurses.
LIBS=""
AC_SEARCH_LIBS(tgetent, [readline ncurses curses termcap])
               ^^^^^^^   ^^^^^^^^ Good, no?  
AC_CHECK_LIB([readline], [readline], [LIBS="$LIBS -lreadline"
  AC_DEFINE(HAVE_READLINE, 1, [Define to 1 if you have the GNU Readline
library.])] )
READLINE_LIBS="$LIBS"
AC_SUBST(READLINE_LIBS)
LIBS="$OLDLIBS"
 
> I find it frustrating.  It makes me wonder if the world of
> Linux is starting to look like the world of M$.  :-(

In this way: management of shared library dependency information is a
thankless task that no one wants to do.  We create one itsy bitsy teewny
weeny yellow polka dot library here (OK, four), and have a dickens of a
time keeping straight what major/minor numbers to bump when.  Multiply our
problem by (something like) the square of the number of libraries on a
typical system, and you have a fair proxy for the size of the problem.  

It's possible to make educated guesses about the compatibilty of a set of
libraries on a system, but impossible to prove it or even state it
definitively.  An audit cannot interrogate or test them directly; the best
that can be done is to compare the versions to some standard.  And that's
how we arrive at Microsoftism: absent a regression test or similar, admins
are forced to rely on conformance to some published "known working" set
a/k/a e.g. RH9.  As packages are added and things get slowly out whack,
the remedy is to upgrade to the vendor's next Big Thing.  

--jkl