Re: building Lua in Ubuntu-12.04

[Drake Wilson <drake@...>]

Quoth Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>, on 2012-12-26 18:13:18 -0200:
> > I built Lua on a fresh Ubuntu 12.04 install recently. IIRC, I had to
> > install the ncurses dev package after I installed the readline dev package.
> 
> Thanks for the feedback. Although that seems consitent with the SO question,
> I find it strange that the readline package (dev or not) does not
> include the ncurses library, on which it seems to depend.

Removing the explicit -lncurses is more correct on most modern
GNU/Linux, such as in the Debian patch Enrico Tassi mentioned.  Here's
why:

In the mainstream GNU/Linux all-shared-libraries world, as far as I
know, it's expected that you only link directly with the libraries you
directly use, and ld.so will pull in the rest as necessary.  A
soname-less .so symlink to the shared library is needed to process a
-l option (since the soname is not specified on the command line), but
not to run the program (since the linker will have included the full
soname in the dynamic section of whatever needs the library).

So the readline dev package is guaranteed to provide enough files to
link with -lreadline, but not necessarily with -lncurses (unless it's
otherwise part of the interface contract), and the readline runtime
package will depend on enough files to load ncurses if readline needs
it, but not necessarily be able to link new programs against it.

This makes more sense in a shared-library environment, since it means
that if a later compatible version of readline does not use ncurses,
existing applications will not needlessly depend on it and load it
themselves.  However, it is inconsistent with the static library case,
where linking an application requires specifying the entire dependency
order manually.  This is kind of unfortunate, but in the static case
there aren't the subtle runtime quasi-bugs that can occur from
excessive -l options in the shared case (since one doesn't replace
code without relinking), so in the absence of a static toolchain that
is known to be able to follow library dependencies it's arguably best
to punt the difference to whoever writes the linker command.

   ---> Drake Wilson