Re: porting EGCS to the Cray T3E

Re: porting EGCS to the Cray T3E

[Benjamin Redelings I]

I once tried to compile gcc for the cray.  I told it the cray was an
alpha/OSF2 or something like that.  I actually did get an executable, but
the Cray assembler couldn't understand the assembly.  I think I gave up
then.  Or perhaps I tried to build the GNU binutils and failed...
	But since the cray is just an alpha, I'd think that you should be able to
make egcs work if they have a supported binary format for the files and
libraries.

-benRI

Re: porting EGCS to the Cray T3E

[Toon Moene]

> > [ Whadusay ?  Virtual memory ?  Hah, I could quote Seymour
> >    Cray's opinion on virtual memory here, but this is a decent
> >    mailing list without explicit adult material, so I'll refrain ]

> PLEASE quote, or give a pointer. We all need to lighten up :-)

Huh ?  I thought that, now that we had decided to extend our  
support to Supercomputers, everyone would immediately rush out to  
study the comp.sys.super FAQs.

More specifically, search for

	cray AND memory

in http://www.dejanews.com and thou shalt be enlightened :-)

Cheers,
Toon.

Re: porting EGCS to the Cray T3E

[Martin Knoblauch]

---Toon Moene <toon@moene.indiv.nluug.nl> wrote:
>
> 
> 2. The T3E has a single global address space.  This means that any
>    processing element can access (read/write) the memory belonging
>    to any other PE; the necessary physical transfer of data is
>    handled by the interconnect.  I think I recall (!) that the global
>    addressing is accomplished by encoding the PE number in the upper 
>    bits of the address.
> 
>    [ Whadusay ?  Virtual memory ?  Hah, I could quote Seymour
>      Cray's opinion on virtual memory here, but this is a decent
>      mailing list without explicit adult material, so I'll refrain ]
>

 PLEASE quote, or give a pointer. We all need to lighten up :-)
 
Martin
===
------------------------------------------------------
Martin Knoblauch
email: knobi@knobisoft.de or knobi@rocketmail.com
www:   http://www.knobisoft.de
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: porting EGCS to the Cray T3E

[Toon Moene]

I wrote:

>  A T3E is just a bunch of 21164 Alpha's interconnected in
>  an interesting way.  If the C library on the system is
>  not really botched up beyond repair, it shouldn't be
>  impossible to create an alphaev5-unicosmk-cray target.
>  However, this is about as much as I know about this topic,
>  so people with more info are kindly requested to step
>  forward.

As pointed out by Martin Knoblauch <knobi@rocketmail.com>, it  
should be alphaev5-cray-unicosmk, and as Julian C. Cummings  
<julianc@acl.lanl.gov> pointed out, the assembly language on the  
Cray is different from that on Digital Unix and the Free Unixen that  
have an Alpha port.  In fact, even though I only spent a few hours  
on a T3E January last year - and didn't have time to dig into the  
assembly language outcome of my compiles - I wouldn't be surprised [  
given previous experience with products from Mr. Cray ] that

	mulf	$f21, $f22, $f23

should be encoded as

	FX23	X21*X22

and

	shl	$11, $12, $13

as

	BA13	A11<A12

:-)

Some more serious observations vis-a-vis the T3E (all IIRC):

1. The operating system is micro-kernel based, but it's UNICOS (the
   vector computer's OS) compatible, i.e. it has a SYSV
   attitude^H^H^H^H^H^Hpersonality.

2. The T3E has a single global address space.  This means that any
   processing element can access (read/write) the memory belonging
   to any other PE; the necessary physical transfer of data is
   handled by the interconnect.  I think I recall (!) that the global
   addressing is accomplished by encoding the PE number in the upper 
   bits of the address.

   [ Whadusay ?  Virtual memory ?  Hah, I could quote Seymour
     Cray's opinion on virtual memory here, but this is a decent
     mailing list without explicit adult material, so I'll refrain ]

3. Last but not least, the Alpha's inside a T3E are operated in
   big-endian mode.  Little-endian is for peecee's (it's not called
   *little*-endian for nothing).

Hope this helps,
Toon.

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

On Jul 14, 12:00pm, Jeffrey A Law wrote:
> Subject: Re: porting EGCS to the Cray T3E
>
>   >  I get the exact same behavior as before.  It works for a while, then
says
>   >
>   > Configuration alpha-cray-unicosmk not supported
> This isn't going to help your problem -- there is no support for cray
> targets.  As long as you continue to try and build for a cray target
> this is going to fail.
> jeff

I see now why choosing "alpha" as a target won't work.  There is a small
assembly language program in config.guess used to distinguish different
types of Alpha processors.  But this does not compile on the T3E; the
assembly language is different.

So what would it take for Cygnus to make egcs portable to the Cray T3E?
(i.e., how hard is it?, what would it cost?, etc.)
egcs would be extremely useful on Cray machines, since Cray CC is terrible
and KAI is very slow to update versions of KCC on the T3E.

Julian C.



-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

>>  not 100% sure, but as the T3D/E are Alpha based systems,
>> the name should probably be "alpha-cray-unicosmk". Then you
>> should go to the "gcc/config/alpha" directory and create
>> the necessary config files. Next step would be to step-by-step
>> eliminate the error messages from "configure" ... It seems
>> that you are at least missing a few libraries and header
>> files. They may have different names, or are at different places.

OK, I will try this.  I don't quite understand your comment about
eliminating error messages from the configure output.  I thought
the purpose of the configure script was to determine what capabilities
the system does and does not have.  An "error" should not be fatal; it
just directs the configure script not to use features that are not
available on the system.

>>  What kind of Unix (BSD, SYSV, OSF) is unicosmk? Never got
>> in touch with it when I was working for SGI/Cray.
>>
>> Martin

I'm not sure how to answer your question.  UnicosMK is a microkernel
variant of Cray's Unicos operating system, designed to fit on individual
nodes of an MPP machine like the T3E.  Unicos has been around for a while.

Julian C.


-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807141424.ZM5539@vapor.acl.lanl.gov >you write:
  > So what would it take for Cygnus to make egcs portable to the Cray T3E?
  > (i.e., how hard is it?, what would it cost?, etc.)
  > egcs would be extremely useful on Cray machines, since Cray CC is terrible
  > and KAI is very slow to update versions of KCC on the T3E.
Note that Cygnus != egcs.

egcs is a project to help build a better free compiler.  Cygnus happens
to be donating various resources to the project (both manpower and
physical resources).

--

Now, having said that, you would need to contact sales@cygnus.com to
get information about a port to the Cray T3E.


jeff

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

On Jul 14, 11:20am, Jeffrey A Law wrote:
> Subject: Re: porting EGCS to the Cray T3E
>
>   In message < 9807141122.ZM4885@vapor.acl.lanl.gov >you write:
>   > I guess I don't understand your comment.  There are other Cray platforms
listed
>   > as possibilities in the config.sub file, such as the Cray X-MP, Y-MP,
Cray  2,
>   > and Cray [C,J,T]90.  Why would these options be listed if Cray is
>   > not supported?
> They may be supported as host or build machines, but that does not
> mean they are supported as a target.
>
> ie, gcc does not know how to generate code for any cray that I'm aware of.

OK.  As far as I can tell, the egcs build instructions do not make any sort of
distinction like this between "host" and "target".  The instructions imply that
these are the same thing.  Nevertheless, I tried the suggestion I received of
setting the host to "alpha-cray-unicosmk" to see if that works.  It does not.
 I get the exact same behavior as before.  It works for a while, then says

Configuration alpha-cray-unicosmk not supported
Configure in /usr/tmp/julianc/EGCS/egcs-objdir-alpha/gcc failed, exiting.

It sounds like you're saying that egcs cannot generate code for a Cray.  But
these are DEC Alpha processors, so I don't see why not.

Is there some sort of verbosity switch I can throw that might tell me why this
is failing?  There is nothing telltale in the config.log file, as you saw.

Julian C.




-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807141146.ZM5055@vapor.acl.lanl.gov >you write:

  > OK.  As far as I can tell, the egcs build instructions do not make any sort of
  > distinction like this between "host" and "target".  The instructions imply that
  > these are the same thing.  Nevertheless, I tried the suggestion I received of
  > setting the host to "alpha-cray-unicosmk" to see if that works.  It does not.
No, look at configure.html



To configure egcs: 


     % mkdir objdir 
     % cd objdir 
     % srcdir/configure [target] [options] 

target specification 

     egcs has code to correctly determine the correct value for target for nearly all native
     systems. Therefore, we highly recommend you not provide a configure target when
     configuring a native compiler. 
     target must be specified when configuring a cross compiler; examples of valid targets
     would be i960-rtems, m68k-coff, sh-elf, etc. 


  >  I get the exact same behavior as before.  It works for a while, then says
  > 
  > Configuration alpha-cray-unicosmk not supported
This isn't going to help your problem -- there is no support for cray
targets.  As long as you continue to try and build for a cray target
this is going to fail.
jeff

Re: porting EGCS to the Cray T3E

[Toon Moene]

  In message < 9807131529.ZM1628@vapor.acl.lanl.gov >you write:
  > the config.log output from egcs-objdir/gcc.  I don't see offhand 
  > why the configuration failed.

  > configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir
  > --host=crayt3e

>  It probably failed because it thought you also wanted to
>  *target* for a cray, which isn't supported.

Some Crays are more equal than others :-)

A T3E is just a bunch of 21164 Alpha's interconnected in an  
interesting way.  If the C library on the system is not really  
botched up beyond repair, it shouldn't be impossible to create an  
alphaev5-unicosmk-cray target.  However, this is about as much as I  
know about this topic, so people with more info are kindly requested  
to step forward.

[ I never did more than building diffutils-2.7, make-3.75 and rcs-5.7
  on it ]

Cheers,
Toon.

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807141122.ZM4885@vapor.acl.lanl.gov >you write:
  > I guess I don't understand your comment.  There are other Cray platforms listed
  > as possibilities in the config.sub file, such as the Cray X-MP, Y-MP, Cray  2,
  > and Cray [C,J,T]90.  Why would these options be listed if Cray is
  > not supported?
They may be supported as host or build machines, but that does not
mean they are supported as a target.

ie, gcc does not know how to generate code for any cray that I'm aware of.

jeff

Re: porting EGCS to the Cray T3E

[Julian C. Cummings]

>> It probably failed because it thought you also wanted to *target* for
>> a cray, which isn't supported.
>>
>> jeff

I guess I don't understand your comment.  There are other Cray platforms listed
as possibilities in the config.sub file, such as the Cray X-MP, Y-MP, Cray 2,
and Cray [C,J,T]90.  Why would these options be listed if Cray is not
supported?

Julian C.


-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov

Re: porting EGCS to the Cray T3E

[Martin Knoblauch]

Julian,

 not 100% sure, but as the T3D/E are Alpha based systems,
the name should probably be "alpha-cray-unicosmk". Then you
should go to the "gcc/config/alpha" directory and create
the necessary config files. Next step would be to step-by-step
eliminate the error messages from "configure" ... It seems
that you are at least missing a few libraries and header
files. They may have different names, or are at different places.

 What kind of Unix (BSD, SYSV, OSF) is unicosmk? Never got
in touch with it when I was working for SGI/Cray.


Martin
===
------------------------------------------------------
Martin Knoblauch
email: knobi@knobisoft.de or knobi@rocketmail.com
www:   http://www.knobisoft.de







---"Julian C. Cummings" <julianc@acl.lanl.gov> wrote:
>
> Hi,
> 
> I am interested in trying to port the EGCS compiler to the Cray T3E.
 I am
> using a June 13th snapshot of the EGCS sources.  I unpacked the
sources and
> created a directory egcs-objdir for building the compiler.  The
first thing I
> discovered when I tried to run the configure script was that it is
not familiar
> with the Cray T3E architecture.  So I edited the config.sub file and
added a
> case for the host type "crayt3e" which sets basic_machine to
"crayt3e-cray" and
> sets os to
> "-unicosmk".  (This is based on what you get when you run "uname -m"
and "uname
> -v" on the T3E.)  Then I ran configure like this:
> 
> configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir --host=crayt3e
> 
> It told me it was creating a Makefile, then it whirred for a while,
and finally
> it came back and reported a failure in configuring egcs-objdir/gcc. 
Below is
> the config.log output from egcs-objdir/gcc.  I don't see offhand why
the
> configuration failed.  If anyone can help me with interpreting the
configure
> output and understanding this problem, I would very much appreciate
it.  Is the
> EGCS compiler supposed to be directly portable to Cray platforms in
this way?
> 
> Thanks, Julian C.
> 
> 
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: porting EGCS to the Cray T3E

[Jeffrey A Law]

  In message < 9807131529.ZM1628@vapor.acl.lanl.gov >you write:
  > the config.log output from egcs-objdir/gcc.  I don't see offhand why the
  > configuration failed.
 
  > configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir --host=crayt3e

It probably failed because it thought you also wanted to *target* for
a cray, which isn't supported.

jeff

porting EGCS to the Cray T3E

[Julian C. Cummings]

Hi,

I am interested in trying to port the EGCS compiler to the Cray T3E.  I am
using a June 13th snapshot of the EGCS sources.  I unpacked the sources and
created a directory egcs-objdir for building the compiler.  The first thing I
discovered when I tried to run the configure script was that it is not familiar
with the Cray T3E architecture.  So I edited the config.sub file and added a
case for the host type "crayt3e" which sets basic_machine to "crayt3e-cray" and
sets os to
"-unicosmk".  (This is based on what you get when you run "uname -m" and "uname
-v" on the T3E.)  Then I ran configure like this:

configure --prefix=/usr/tmp/julianc/EGCS/egcs-objdir --host=crayt3e

It told me it was creating a Makefile, then it whirred for a while, and finally
it came back and reported a failure in configuring egcs-objdir/gcc.  Below is
the config.log output from egcs-objdir/gcc.  I don't see offhand why the
configuration failed.  If anyone can help me with interpreting the configure
output and understanding this problem, I would very much appreciate it.  Is the
EGCS compiler supposed to be directly portable to Cray platforms in this way?

Thanks, Julian C.



This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:757: checking host system type
configure:778: checking target system type
configure:796: checking build system type
configure:823: checking for gcc
configure:900: checking whether the C compiler (cc -g ) works
configure:914: cc -o conftest -g   conftest.c  1>&5
configure:934: checking whether the C compiler (cc -g ) is a cross-compiler
configure:939: checking whether we are using GNU C
configure:991: checking whether make sets ${MAKE}
configure:1024: checking for mawk
configure:1024: checking for gawk
configure:1024: checking for nawk
configure:1055: checking for flex
configure:1088: checking for yywrap in -lfl
configure:1107: cc -o conftest -g   conftest.c -lfl   1>&5
cld-315 cld: ERROR
  The library file `libfl.a' was not found.
cld-117 cld: FATAL
  Errors occurred processing the input files.
configure: failed program was:
#line 1096 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char yywrap();

int main() {
yywrap()
; return 0; }
configure:1130: checking whether ln works
configure:1162: checking whether ln -s works
configure:1194: checking for volatile
configure:1206: cc -c -g  conftest.c 1>&5
configure:1229: checking for ranlib
configure:1260: checking for bison
configure:1300: checking for a BSD compatible install
configure:1351: checking how to run the C preprocessor
configure:1412: checking for ANSI C header files
configure:1516: checking whether time.h and sys/time.h may both be included
configure:1530: cc -c -g  conftest.c 1>&5
configure:1554: checking for limits.h
configure:1554: checking for stddef.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for string.h
configure:1554: checking for strings.h
configure:1554: checking for stdlib.h
configure:1554: checking for time.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for fcntl.h
configure:1554: checking for unistd.h
configure:1554: checking for stab.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
CC-5 cc: ERROR File = configure, Line = 1560
  The source file "stab.h" is unavailable.

  #include <stab.h>
                   ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1559 "configure"
#include "confdefs.h"
#include <stab.h>
configure:1554: checking for sys/file.h
configure:1554: checking for sys/time.h
configure:1554: checking for sys/resource.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for sys/param.h
configure:1554: checking for sys/times.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1554: checking for wait.h
configure:1564: cc -E  conftest.c >/dev/null 2>conftest.out
CC-5 cc: ERROR File = configure, Line = 1560
  The source file "wait.h" is unavailable.

  #include <wait.h>
                   ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1559 "configure"
#include "confdefs.h"
#include <wait.h>
configure:1554: checking for sys/wait.h
configure:1594: checking for thread.h
configure:1604: cc -E  conftest.c >/dev/null 2>conftest.out
CC-5 cc: ERROR File = configure, Line = 1600
  The source file "thread.h" is unavailable.

  #include <thread.h>
                     ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1599 "configure"
#include "confdefs.h"
#include <thread.h>
configure:1628: checking for pthread.h
configure:1638: cc -E  conftest.c >/dev/null 2>conftest.out
configure:1664: checking whether cpp understands the stringify operator
configure:1677: cc -c -g  conftest.c 1>&5
configure:1700: checking for inttypes.h
configure:1713: cc -c -g  conftest.c 1>&5
CC-5 cc: ERROR File = configure, Line = 1707
  The source file "inttypes.h" is unavailable.

  #include <inttypes.h>
                       ^

1 catastrophic error detected in the compilation of "conftest.c".
Compilation terminated.
configure: failed program was:
#line 1705 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <inttypes.h>
int main() {
intmax_t i = -1;
; return 0; }
configure:1736: checking for strtoul
configure:1736: checking for bsearch
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for strerror
configure:1736: checking for putenv
configure:1736: checking for popen
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for bcopy
configure:1736: checking for bzero
configure:1736: checking for bcmp
configure:1736: checking for index
configure:1736: checking for rindex
configure:1736: checking for strchr
configure:1736: checking for strrchr
configure:1736: checking for kill
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for getrlimit
configure:1764: cc -o conftest -g   conftest.c  1>&5
cld-404 cld: WARNING
  The symbol `getrlimit' referenced in relocatable object
`conftest.o:conftest$c' is not defined.
cld-431 cld: WARNING
  The resulting output file `conftest' is not executable because of previous
WARNING messages.
configure: failed program was:
#line 1741 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char getrlimit(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char getrlimit();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_getrlimit) || defined (__stub___getrlimit)
choke me
#else
getrlimit();
#endif

; return 0; }
configure:1736: checking for setrlimit
configure:1764: cc -o conftest -g   conftest.c  1>&5
cld-404 cld: WARNING
  The symbol `setrlimit' referenced in relocatable object
`conftest.o:conftest$c' is not defined.
cld-431 cld: WARNING
  The resulting output file `conftest' is not executable because of previous
WARNING messages.
configure: failed program was:
#line 1741 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char setrlimit(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char setrlimit();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_setrlimit) || defined (__stub___setrlimit)
choke me
#else
setrlimit();
#endif

; return 0; }
configure:1736: checking for atoll
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1736: checking for atoq
configure:1764: cc -o conftest -g   conftest.c  1>&5
cld-404 cld: WARNING
  The symbol `atoq' referenced in relocatable object `conftest.o:conftest$c' is
not defined.
cld-431 cld: WARNING
  The resulting output file `conftest' is not executable because of previous
WARNING messages.
configure: failed program was:
#line 1741 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char atoq(); below.  */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char atoq();

int main() {

/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined (__stub_atoq) || defined (__stub___atoq)
choke me
#else
atoq();
#endif

; return 0; }
configure:1736: checking for sysconf
configure:1736: checking for isascii
configure:1764: cc -o conftest -g   conftest.c  1>&5
configure:1790: checking for vprintf
configure:1906: checking whether the printf functions support %p
configure:1927: cc -o conftest -g   conftest.c  1>&5
configure:1955: checking whether malloc must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether realloc must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether calloc must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether free must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether bcopy must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether bzero must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether bcmp must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether index must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether rindex must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether getenv must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether atol must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether sbrk must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether abort must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:1955: checking whether atof must be declared
configure:1987: cc -c -g  conftest.c 1>&5
configure:2014: checking for sys_siglist declaration in signal.h or unistd.h
configure:2031: cc -c -g  conftest.c 1>&5
CC-20 cc: ERROR File = configure, Line = 2027
  The identifier "sys_siglist" is undefined.

  char *msg = *(sys_siglist + 1);
                ^

1 error detected in the compilation of "conftest.c".
configure: failed program was:
#line 2019 "configure"
#include "confdefs.h"
#include <sys/types.h>
#include <signal.h>
/* NetBSD declares sys_siglist in unistd.h.  */
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif
int main() {
char *msg = *(sys_siglist + 1);
; return 0; }

-- 
Julian C. Cummings
Advanced Computing Laboratory
Los Alamos National Laboratory
(505) 667-6064
julianc@acl.lanl.gov