Niels M?ller wrote:
>
> Gabe Foster <[EMAIL PROTECTED]> writes:
>
> > I've managed to get LSH to compile on an SGI running IRIX6 using the
> > sgi compiler. Patches for 0.2.7 are attached. You need to use a
> > configure line like the following:
> >
> > env CPPFLAGS="-I/usr/local/include" CFLAGS="-D inline=__inline
> > -D__OPTIMIZE__ -I
> > /usr/local/include -I/usr/gnu/include" LDFLAGS="-L/usr/local/lib
> > -L/usr/gnu/lib"
> > LIBS="-lmalloc" ./configure --with-zlib --with-tcp-forward
>
> Good to hear. If you have suggestions for what to put in configure.in
> to do some or all of this automatically, that is also appreciated.
Adding AC_C_INLINE to configure.in will automatically add a #define for
the appropriate inline... and a line in config.h.in. Oh, you mention
that below. I haven't tried with 0.2.7 - before ( 0.2.3 or somewhere
around there ) didn't have the AC_C_INLINE in the configure. It should,
and does, handle that, at least for other packages. The other env
settings are necessary to point the SGI c compiler to libs and includes
it doesn't know about by default, or we want to override the included
(sometimes ancient) versions, so I wouldn't expect those to change. The
only other change, and I don't have an example to give you, as it's been
a while since I hacked autoconf, but adding a check to see if alloca and
or malloc is defined and included in the std C lib, or if -lmalloc is
necessary to get the alloca/malloc stuff would be cool... Perhaps using
AC_CHECK_FUNC or something like that?
<skip stuff that Gabe responded to and I didn't want to add my $0.02>
> Hmm. AC_C_INLINE in configure.in is supposed to define inline as
> __inline, if appropriate. Does that happen for you? What does
> configure say about inline? Do you get any relevant definitions in
> config.h? Or Is it the combination of extern and inline that causes
> problems?
The problem is with the extern... only gcc can deal with extern inline,
which if I remember correctly was something Linus added to gcc for
linux, so particular kernel functions can make sure to not have a stack
frame or something bizarre like that - I can't remember. He at least
cares about that existing for some reason... :)
>
> > diff -c -r lsh-0.2.7/src/argp/argp-parse.c lsh-0.2.7.new/src/argp/argp-parse.c
> > *** lsh-0.2.7/src/argp/argp-parse.c Wed Feb 2 15:59:54 2000
> > --- lsh-0.2.7.new/src/argp/argp-parse.c Thu Feb 3 10:28:22 2000
> > ***************
> > *** 803,809 ****
> > parser, because we pre-compute which parser is supposed to deal
> > with each option. */
> > {
> > ! static const char bad_key_err[] =
> > N_("(PROGRAM ERROR) Option should have been recognized!?");
> > if (group_key == 0)
> > __argp_error (&parser->state, "-%c: %s", opt,
> > --- 803,809 ----
> > parser, because we pre-compute which parser is supposed to deal
> > with each option. */
> > {
> > ! static const char *bad_key_err =
> > N_("(PROGRAM ERROR) Option should have been recognized!?");
> > if (group_key == 0)
> > __argp_error (&parser->state, "-%c: %s", opt,
>
> I don't quite understand what happens here (I didn't write this code).
> Can you explain? Perhaps the bugfix should be sent to the glibc folks.
It's a deal with gcc and how gcc allows you to define variables. I don't
remember all the changes that are in for C9X, but many compilers don't
have those changes. Anyways, N_ is a gettext-ism if I remember
correctly, and so it's acting as a function or something like that (I
don't remember right now), and you can't initialize [] char strings to a
return value in most compilers...
Most of the changes that end up being made to make OSS projects compile
usually have to do with gcc-isms. Most commonly it's things like this,
or initializing variables based on a function argument. This is fine for
C++ and gcc, but good old C doesn't allow anything but a constant for an
initializer, although I believe they've changed that for C9X, but I
don't think many compilers support most of the C9X changes yet (gcc only
supports about half, in terms of 2.95.2)...
>
> > diff -c -r lsh-0.2.7/src/lsh_types.h lsh-0.2.7.new/src/lsh_types.h
> > *** lsh-0.2.7/src/lsh_types.h Mon Jan 10 00:58:47 2000
> > --- lsh-0.2.7.new/src/lsh_types.h Fri Feb 4 07:34:45 2000
> > ***************
> > *** 97,103 ****
> > --- 97,107 ----
> > #if HAVE_STRSIGNAL
> > #define STRSIGNAL strsignal
> > #else
> > + #ifdef __sgi
> > + #define STRSIGNAL(x) (_sys_siglist[x])
> > + #else
> > #define STRSIGNAL(x) (sys_siglist[x])
> > + #endif
> > #endif
>
> This one is pretty obvious. Is #ifdef __sgi the canonical way to test
> for SGI?
>
It's in the SGI header files, so __sgi would seem to be the correct
thing to use...
later,
--
Kimball
mailto:[EMAIL PROTECTED]
---------------
There is a difference between knowing the path and walking the path.
- Morpheus
