Xref: utzoo comp.realtime:1392 comp.lang.c:40004 comp.sys.m68k:2373
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!caen!hellgate.utah.edu!dog.ee.lbl.gov!nosc!cod!healy
From: healy@cod.NOSC.MIL (Mike Healy)
Newsgroups: comp.realtime,comp.lang.c,comp.sys.m68k
Subject: Re: cc68k gnu crosscompiler SPARC/68k20 exits w signal 11
Message-ID: <3131@cod.NOSC.MIL>
Date: 12 Jun 91 21:43:42 GMT
References: <92@nososl.UUCP>
Distribution: comp
Organization: Naval Ocean Systems Center, San Diego
Lines: 39

In article <92@nososl.UUCP> trygg@nososl.UUCP (Trygg A. Eliassen) writes:
>I have just received vxWorks 5.0 with the GNU toolkit.  We are running
>SPARC as host and MIZAR 68k20 targets.  I am compiling with the cc68k
>compiler and compiling some files I get the following message from the compiler before it dies, no files are produced.
> . . . (stuff deleted)
>cc68k: Program as got fatal signal 11.
>*** Error code 1
>make: Fatal error: Command failed for target `geometry.o'
>%
>--  ... (stuff deleted)
>Trygg A. Eliassen BSc. Hons | trygg@nordic-offshore.no
>Nordic Offshore Systems AS  | mcsun!nuug!nososl!trygg
>Stabekk - Oslo - NORWAY     | Tlf +472 12 55 80  Fax +472 12 54 01

I had the exact same problem, but only with one file. When this file was
compiled on a SPARCStation at our customer's site, it would get this
error numerous times before succeeding. Finally, after as many as 10 or
12 attempts, it would compile successfully. None of the other modules
(~ 100 files) had this problem. This never happened at our lab using
a Sun 3/60 and the same vxWorks/gcc (cc68k).  At first I thought that
maybe there was a bad spot on the disk where the file was located, but
in the course of development this file was moved to several different
disks and the problem didn't change.

My solution is that the system is installed and that particular module
no longer needs to be compiled 8^) , but if you find out what's going
on,  please email me or post.  I think the code is forcing the assembler
into a little-used (and not completely debugged) path.

Or you could try compiling it on an old Sun 3 8^)

BTW, our targets are FORCE CPU-30s running vxWorks. I am happy with
vxWorks. Some of our needs are not supported by Wind River (e.g. raw
ethernet datagram multicasting), but they have been very nice about
giving me the source so I could get the job done.

Mike Healy
ETA Technologies
healy@cod.nosc.mil