help-nano
[Top][All Lists]
Advanced

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

Re: [Help-nano] RE: compiling nano on HP-UX


From: Chris Allegretta
Subject: Re: [Help-nano] RE: compiling nano on HP-UX
Date: Thu, 19 Feb 2009 19:56:42 -0500

Hi Jay,

I would rather just put feature-specific checks in configure.ac
whenever possible.  I took a crack at this, can you try the tarball at
http://www.nano-editor.org/dist/test/nano-2.1.9-svn-xopenchk.tar.gz
and let me know whether it works for you?  Thanks much.

On Wed, Feb 18, 2009 at 8:22 PM, Jay <address@hidden> wrote:
> 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
>> >
>




reply via email to

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