Re: ncurses-5.1-20001014.patch.gz

[Johnny C. Lam]

Albert Chin-A-Young <address@hidden> writes:
> 
> FYI, libtool 1.3.5 works fairly well with vendor compilers too (I have
> not tested the libtool support in ncurses yet). The only problem with
> the 1.3.5 version is C++ which does not work well with vendor
> compilers. The multilang branch fixes this though. As ncurses uses
> both C/C++ (though C++ can be turned off), maybe the multilang version
> should be considered.

The changes for libtool use the libtool in the current PATH, or the
one defined in the LIBTOOL environment variable.  It isn't "true"
libtool support in the configure script and build process, only some
modifications to allow one to build with libtool if you already have
it installed (as is the case with the NetBSD Packages Collection).  As
an example, NetBSD's pkgsrc uses a locally modified libtool-1.3.5 that
properly supports C++, ELF and a.out on our 20+ architectures, and
ncurses builds very well with it.

> Also, saying this without having looked at the --with-libtool option,
> do the version numbers of the ncurses library match up if using
> --with-libtool and without?

The libraries are linked by passing libtool the option:

        -version-info $(NCURSES_MAJOR):$(NCURSES_MINOR)

which on a.out and ELF systems create shared libs that look like:

        libncurses.so.$(NCURSES_MAJOR):$(NCURSES_MINOR)

So they match what is normally produced on NetBSD, FreeBSD, Linux, and
(I think) Solaris.

Incidentally, many, _MANY_ thanks to Tom Dickey for accepting this
patch into the main source tree.  It's made maintaining the ncurses in
the NetBSD Packages Collection orders of magnitude easier.  I owe beer
if we ever meet.

     -- Johnny C. Lam <address@hidden>
        Department of Statistics, Carnegie Mellon University
        http://www.stat.cmu.edu/~lamj/