[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
http://invisible-island.net
ftp://invisible-island.net
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden