Re: editors/nvi/

[Steve Mynott <steve%rum.dedrat.com@localhost>]

On Wed, Dec 21, 2011 at 08:26:20PM +1300, Steven Drake wrote:
> On Wed, 21 Dec 2011, Steve Mynott wrote:
> 
> > On Wed, Dec 21, 2011 at 12:38:07PM +1300, Steven Drake wrote:
> > > On Tue, 20 Dec 2011, Steve Mynott wrote:
> > > 
> > > > The following is needed to compile nvi on Linux (Centos 6 tested).
> > > > 
> > > > retrieving revision 1.40
> > > > diff -u -r1.40 Makefile
> > > > --- Makefile    10 Jan 2011 11:06:29 -0000      1.40
> > > > +++ Makefile    20 Dec 2011 14:59:05 -0000
> > > > @@ -36,6 +36,9 @@
> > > >  CONFIGURE_ENV+=                vi_cv_sys5_pty=no
> > > >  LDFLAGS+=              -flat_namespace
> > > >  INSTALL_UNSTRIPPED=    yes
> > > > +.elif ${OPSYS} == "Linux"
> > > > +CONFIGURE_ENV+=                vi_cv_include_sys_select=no
> > > > +CONFIGURE_ENV+=                vi_cv_sys5_pty=no
> > > >  .endif
> > > 
> > > No it's not, nvi builds find for me.
> > 
> > On which distribution?
> 
> The distribution won't make any difference.

I think your distribution (like my Debian box) has sys/stropts.h whereas 
CentOS 6 (via RHEL6) has deprecated (perhaps over agressively?)  
use of this header file.

https://bugzilla.redhat.com/show_bug.cgi?id=457897

since I get the following error trying to build editors/nvi using
HEAD as of today:

(I'm using bootstrap with --unprivileged if this makes any difference..)

[...snip]
btool: compile:  gcc -DHAVE_CONFIG_H -I. -I../dist -D__REGEX_PRIVATE -I../dist
/../include -DVI=\"/home/pkgsrc/pkg/bin/nvi-ipc\" -I../dist/../regex -I/home/pkg
src/pkgsrc/editors/nvi/work/.buildlink/include -I/home/pkgsrc/pkgsrc/editors/nvi
/work/.buildlink/include/db4 -O2 -Wno-error -c ../dist/../ex/ex_script.c  -fPIC
-DPIC -o .libs/ex_script.o
../dist/../ex/ex_script.c:27:25: error: sys/stropts.h: No such file or directory
[...snip]

nvi does build on CentOS 6 using my patch.
 
This header file is present in the "compat-glibc-headers" RPM
as /usr/lib/i686-redhat-linux5E/include/sys/stropts.h.

(I'm not sure if this file is commonly installed on RHEL 6 derived systems)

Maybe another fix (better?) would be use this header on such systems?

Any thoughts?

Cheers Steve