When I execute the the runhugs.lhs on Sun4 and Solaris machines.
My output was consistant with Graeme's.
When I run it on a Linux machine, my output was consistant with
Alastair's.
this was using runhugs version 971118
Info about Machines-------------------
Sun4:
* gcc version 2.7.2
* SunOS 4.1.3_U1
Solaris:
* SunOS 5.5.1
* gcc version 2.7.2
Linux:
* gcc version 2.7.0
* Linux 2.0.20
here is the output from configure which i ran on the sun4:
-----------------------------------------------------------------
$ LIBS="-L/usr/local/gnu/lib -liberty" ./configure --with-readline
--disable-large-banner --datadir=/projects/pacsoft/haskell
creating cache ./config.cache
checking for bison... bison -y
checking for gcc... gcc
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for perl... perl
checking whether make sets ${MAKE}... yes
checking for hp2ps... 0
checking for diff... /usr/bin/diff
checking whether to use diff -c1 or diff -C 1... No differences encountered
/usr/bin/diff -c1
checking for function_dlopen... yes
checking for function_shl_load... no
checking for library_dld... no
checking for function_atan... no
checking for library_m... yes
checking whether cross-compiling... no
checking for ANSI C header files... no
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for sys/param.h... yes
checking for stdarg.h... yes
checking for stdlib.h... yes
checking for unistd.h... yes
checking for assert.h... yes
checking for ctype.h... yes
checking for string.h... yes
checking for fcntl.h... yes
checking for sgtty.h... yes
checking for termio.h... yes
checking for termios.h... yes
checking for signal.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for sys/ioctl.h... yes
checking for sys/resource.h... yes
checking for console.h... no
checking for pascal.h... no
checking for Files.h... no
checking for errno.h... yes
checking for stat.h... no
checking for nlist.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for time.h... yes
checking for sys/time.h... yes
checking for float.h... yes
checking for values.h... yes
checking for dos.h... no
checking for conio.h... no
checking for io.h... no
checking for std.h... no
checking for windows.h... no
checking for dlfcn.h... yes
checking for dl.h... no
checking for alloc.h... no
checking for malloc.h... yes
checking for valloc... yes
checking for strcasecmp... yes
checking for _stricmp... no
checking for stricmp... yes
checking for strcmpi... no
checking for strcmp... yes
checking for realpath... yes
checking for _fullpath... no
checking for PBHSetVolSync... no
checking for macsystem... no
checking for fgetpos... no
checking for fsetpos... no
checking for fseek... yes
checking for ftell... yes
checking for vsnprintf... no
checking for _vsnprintf... no
checking for snprintf... no
checking for _snprintf... no
checking for popen... yes
checking for _popen... no
checking for pclose... yes
checking for _pclose... no
checking for working alloca.h... yes
checking for alloca... yes
checking for _alloca... no
checking for stime... no
checking for poly... no
checking for working const... yes
checking prototypes... yes
checking for arrays of jmp_bufs... yes
checking labels as values... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking return type of signal handlers... void
checking whether gcc needs -traditional... no
checking for a leading underscore in symbol names
checking for ld... ld
checking for -lreadline... yes
checking size of int... 4
checking size of float... 4
checking size of double... 8
checking size of int*... 4
building large hugs
updating cache ./config.cache
creating ./config.status
creating ../Makefile
creating ../Tests/testScript
creating ../config.h
../config.h is unchanged
creating ../options.h
../options.h is unchanged
************************************************
*** NOW DO: cd .. followed by make install
************************************************
byron
On Fri, 5 Dec 1997, Alastair Reid wrote:
>
> Graeme Moss <[EMAIL PROTECTED]> reports:
> > I have never got any error messages reported correctly by runhugs and
> > have always assumed that this was due to runhugs not being completed
> > yet (as there was no reference to runhugs in the manual of 20/6/97).
>
> Runhugs has been documented since sometime in April - though the
> documentation consists of using the source code to explain the Hugs
> Server API (hugs/docs/server.{tex,html}. :-)
>
> > Now there is a reference to runhugs in the latest manual (4/12/97)
> > perhaps this is a bug?
> >
> > [details omitted]
> >
> > I presume this is either:
> >
> > a) known about, in which case, I apologise (but I couldn't find any
> > reference to it),
> >
> > b) a problem at my end, in which case, we should isolate the problem.
> >
> > Then again, it could just be a plain bug. :-)
>
> I'm going for option (b) On my Linux box, I get the following output
> from your three programs:
>
> [reid@haggis reid]$ runhugs foo
> runhugs: Error occurred
> Reading file "foo":
> Parsing
> ERROR "foo" (line 1): Syntax error in input (unexpected symbol ">")
>
>
> [reid@haggis reid]$ runhugs +l foo
> Hello world!
> [reid@haggis reid]$ runhugs +l foo
> runhugs: Error occurred
> Reading file "foo":
> Dependency analysis
> ERROR "foo" (line 3): Undefined variable "putSt"
>
>
> [reid@haggis reid]$ runhugs +l foo
>
> Program error: Hello?runhugs: Error occurred
>
> The final error message could be a bit more informative but I'm definitely
> getting more information than you are. Can you send me:
>
> o The output generated by running configure.
> (If you are installing Hugs on multiple machines, it's probably
> a good idea to first delete config.cache so there's no confusion)
>
> o A description of your environment (OS vendor+version, compiler
> vendor+version, etc). A combination of uname and gcc -V or cc -v
> often does the trick.
>
>
> Alastair
>
> ps Sorry things have been quiet here this week - we had to scrub my
> disk clean and reinstall everything on my machine after some
> hackers got in. Also, if anyone sent in a bug report yesterday
> morning (or the night before?) and hasn't seen a response, you
> probably ought to resend - I lost about a dozen messages.
> Finally, Win95 users shouldn't bother with the latest Hugs Beta
> - we still haven't fixed got a convenient fix for the msvcrt40.dll
> problem.
>
>
>
>
