|
From: | Jay |
Subject: | RE: [Help-nano] RE: compiling nano on HP-UX |
Date: | Thu, 19 Feb 2009 01:22:56 +0000 |
Chris, no problem, no rush. It is working for me. tarball or svn should be ok. (I've never used command line svn, but have used cvs, so... and I don't have svn on this machine yet, but can always go through another..) If you are worried about: fips_rand.c:59:1: warning: "_XOPEN_SOURCE_EXTENDED" redefined http://rt.openssl.org/Ticket/Display.html?id=1026&user=guest&pass=guest You can either do #undef _XOPEN_SOURCE_EXTENDED #define _XOPEN_SOURCE_EXTENDED Are there values other than 1? Like defining it to a date/version-thing? or #ifndef _XOPEN_SOURCE_EXTENDED #define _XOPEN_SOURCE_EXTENDED #endif but having configure only #define it if it "helps" is also reasonable. Maybe there are other problems. Another thing you can do, a little icky maybe, but maybe nicer than adding configurey :) is isolating the code that needs it so as to minimize the risk. You know, little wrapper functions and extern consts, with some alternate names, that just wrap the "real" stuff. Perhaps that's not the best source organization though. stdarg.h you can either put in unconditionally, should be safe. This system has a K&R compiler but I think still has stdarg.h. As well, it need only go in under the same situation -- tied to the use of #define _XOPEN_SOURCE_EXTENDED. SIMILARY, I had some source yesterday (not nano, not HP-UX) that required #define _GNU_SOURCE or such. g++ predefined it, gcc did not. So I had to do that #undef to fix that very same warning. It was C code but I like to check that it compiles as C++ too. - Jay > Date: Wed, 18 Feb 2009 19:44:07 -0500 > Subject: Re: [Help-nano] RE: compiling nano on HP-UX > From: address@hidden > To: address@hidden > CC: address@hidden > > Hi Jay, > > Thanks for this report. Unfortunately, from what i read about > _XOPEN_SOURCE_EXTENDED it sounds like it may change other behaviors as > well by defining it. I think I will have to add a check to the > configure script to test whether the colors are available without > defining _XOPEN_SOURCE_EXTENDED, and then try it with the flag and set > it properly if needed, and then if needed define it. This will > probably take a day or two, but are you willing to test out a tarball > if I create one for you, or do you have subversion access? > > The stdarg stuff should be easy to check for as well via configure. > > On Tue, Feb 17, 2009 at 4:50 PM, Jay <address@hidden> wrote: > > > > The include is of stdarg.h with angle brackets. > > My email is getting munged, sorry. > > > > - Jay > > > > > > > > ---------------------------------------- > >> From: address@hidden > >> To: address@hidden > >> Subject: FW: compiling nano on HP-UX > >> Date: Tue, 17 Feb 2009 15:34:44 +0000 > >> > >> > >> [bounced there] > >> > >> > >> > >> From: jay.krell@ > >> To: nano-devel@ > >> Subject: compiling nano on HP-UX > >> Date: Tue, 17 Feb 2009 15:20:58 +0000 > >> > >> > >> > >> nano-2.1.9 > >> > >> > >> -bash-3.2$ gcc -v > >> Reading specs from /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.6/specs > >> Configured with: /src/gcc-3.3.6/configure -verbose -with-as=/usr/local/bin/gas -with-gnu-as > >> Thread model: single > >> gcc version 3.3.6 > >> > >> > >> -bash-3.2$ uname -a > >> HP-UX jkhpux1 B.11.11 U 9000/800 1595760578 unlimited-user license > >> This is I think "11v1". > >> > >> > >> color.c: In function `color_init': > >> color.c:86: error: `COLOR_WHITE' undeclared (first use in this function) > >> color.c:86: error: (Each undeclared identifier is reported only once > >> color.c:86: error: for each function it appears in.) > >> color.c:93: error: `COLOR_BLACK' undeclared (first use in this function) > >> gmake: *** [color.o] Error 1 > >> -bash-3.2$ pwd > >> /src/nano-2.1.9/src > >> -bash-3.2$ cp color.c color.c.orig > >> > >> > >> > >> put #define _XOPEN_SOURCE_EXTENDED at the top of color.c > >> => /usr/local/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.6/include/curses.h:755: error: syntax error > >> before "va_list" > >> > >> > >> put #include at the top of color.c > >> => works > >> > >> > >> I don't have GNU diff yet: > >> -bash-3.2$ diff color.c.orig color.c > >> 23a24,25 > >>> #define _XOPEN_SOURCE_EXTENDED > >>> #include > >> > >> > >> Either order compiles, but this seems better. > >> > >> > >> rcfile.c: In function `color_to_short': > >> rcfile.c:543: error: `COLOR_GREEN' undeclared (first use in this function) > >> rcfile.c:543: error: (Each undeclared identifier is reported only once > >> rcfile.c:543: error: for each function it appears in.) > >> rcfile.c:545: error: `COLOR_RED' undeclared (first use in this function) > >> > >> same thing. > >> > >> -bash-3.2$ diff rcfile.c.orig rcfile.c > >> 23a24,25 > >>> #define _XOPEN_SOURCE_EXTENDED > >>> #include > >> > >> > >> and then it builds and works. > >> > >> > >> Thanks, > >> - Jay > > > > _______________________________________________ > > Help-nano mailing list > > address@hidden > > http://lists.gnu.org/mailman/listinfo/help-nano > > |
[Prev in Thread] | Current Thread | [Next in Thread] |