Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!msc@ramoth.SGI.COM
From: msc@ramoth.SGI.COM (Mark Callow)
Newsgroups: comp.windows.news
Subject: Re: NeWS For VaxStations (Micro Vaxes, etc)
Summary: the problem is with NeWS
Message-ID: <33046@sgi.SGI.COM>
Date: 17 May 89 19:07:14 GMT
References: <8905132111.AA19260@fnord.umiacs.UMD.EDU> <23810@pprg.unm.edu>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 30

In article <23810@pprg.unm.edu>, cyrus@pprg.unm.edu (Tait Cyrus) writes:

> Yes, the sources you get from Sun are for Ultrix 2.2 (2.something).  Working
> with Los Alamos National Laboratory (Group MEE-10), I was able to get NeWS
> running on a VS2000 (QVSS display only).  I also started to play with
> a DS3100 port, but real work got in the way.  Before I dropped it, though,
> I was able to get NeWS to compile but not run.  I was getting a seg fault
> BEFORE it even got the the good stuff (the graphics).  
> 
> From experience we (UNM) have with the DS3100, I think my problem is 
> as a result of the DS3100 (MIPS) compiler rather than the NeWS source, 
> though I did not REALLY have time to track the problem down to see if
> Sun had done something that was not kosher.

The problem is that NeWS assumes that 26 bits is enough for the pointer
(offset) from the object to the object body.  Since the MIPS loader
chooses to place the data segment at 0x10000000, you need 28 bits.

There is a flag to our (SGI's) MIPS loader, -D, that lets you put the
data segment somewhere else.  If it works then one solution is to move
the data segment down but beware of the shared libraries.
Our ld(1) man page says -D is "machine dependent and may not work on all
implementations".   It may not even be a workable solution on ours.  -D
didn't exist when I first ported NeWS to the IRIS.  I was faced with a
couple of ugly choices:  increase the object structure size or OR in the
unchanging high bits of the address.  I chose the latter.


--
	-Mark