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 [EMAIL PROTECTED]
