[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev configure problem with 2.8.5 on SunOS 5.9

From: Thomas Dickey
Subject: Re: lynx-dev configure problem with 2.8.5 on SunOS 5.9
Date: Thu, 19 Feb 2004 21:00:34 -0500 (EST)

On Fri, 20 Feb 2004, Henry Nelson wrote:

> On Thu, Feb 19, 2004 at 07:30:08AM -0500, Webmaster Jim wrote:
> > "old" curses, but the makefiles being generated are trying to use
> > ncurses.
> The question I have is not directly related to Jim's, but to building/
> linking with ncursesw on NetBSD 1.6.
>                     ^
> What are the correct CPPFLAGS and LIBS (or LDFLAGS) environment variables
> when ncurses-5.4 is built with the following configure options?
>   --prefix=/usr/local
>   --disable-overwrite
>   --enable-widec
>   --without-curses-h
> Would I be better off not using that last option, "--without-curses-h"?

Not really.  --disable-overwrite puts the header files in a subdirectory
which normally is not part of the include-path.  Lynx's configure script
checks for the subdirectory.  So (in the case you're talking about), you
really only need -I/usr/local/include in $CPPFLAGS.

> Haven't gotten to Lynx yet, but nvi is giving me trouble with:
>   CPPFLAGS="-I/usr/local/include/ncursesw"
>   LIBS="-L/usr/local/lib -lncursesw"
> Should CPPFLAGS simply point to "/usr/local/include", (and therefore it's
> possible to omit the path to header files)?
> Specifically, at line 42 of "/usr/local/include/ncursesw/termcap.h"
> there is "#include <ncursesw/ncurses_dll.h>".  Shouldn't that be:
> "#include <ncurses_dll.h>" since we're already in "ncursesw/"?

No - it's assuming that the files are in <ncursesw/xxx>.  If I'd put
curses.h in /usr/local/include rather than /usr/local/include/ncurses
or /usr/local/include/ncursesw, then gcc picks up that ahead of the
/usr/include/curses.h - not good if you're allowing for building with
either flavor of curses.  Adding -I/usr/include "fixes" it - if the
program doesn't happen to use some of gcc's "fixed" includes(*).

Most gcc installs automatically add -I/usr/local/include, producing this
problem.  I've noticed that the various *BSD ports FreeBSD/NetBSD/OpenBSD
disable that feature (I should add a configure check for _that_, so I
don't have to add it back ;-)

(*) "fixed" includes originally ANSIfy'd system headers to make gcc run
better.  But it doesn't really do that any more - except as an
afterthought, since gcc's extensions & non-standardisms are what I see
in the "fixed" includes.

Thomas E. Dickey

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]