Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shlump.nac.dec.com!engage!ootool.dec.com!tenny
From: tenny@ootool.dec.com (Dave Tenny)
Newsgroups: comp.sys.next
Subject: Information on broken Lisp's on 68030 cubes running 2.0 software
Message-ID: <1991Feb28.144436.7961@engage.enet.dec.com>
Date: 28 Feb 91 14:45:04 GMT
Sender: news@engage.enet.dec.com (USENET News System)
Organization: Digital Equipment Corporation
Lines: 111



A couple of weeks ago, people were asking about why Lisp didn't work
as advertised when upgrading from 1.0 to 2.0 software.  The nice people
at NeXT provided me a patch to make ACL work under 2.0, but it only
works for 2.0 systems on 68030's.  Lisp on 68040's must have the formal
upgrade which hasn't been made available yet.

Here is the reply from the person at NeXT, who isn't permitted to
post to this group, so I'll post for her, removing names to protect
the thoughtful.

Dave
------------------------------------------------------------------------------
Subj:	Making Common Lisp work under 2.0 

A NextAnswer for you about massaging Common Lisp to work under  
Release 2.0.

Franz Allegro Common Lisp 2.0 1.0

Q:  Why can't I use my 1.0 version of Franz Allegro Common Lisp under  
2.0?  Is there something I can do to make it work until an update  
becomes available?

A:  The 1.0 release of Common Lisp does not work with Release 2.0 for  
several reasons:
	1. the Mach header of the .o files have some uninitialized  
fields
	2. the libNeXT and libdsp have some incompatibilities and  
cannot be used
	3. foreign loading doesn't quite work
	
(and perhaps other unknown things). The 1.0 version may be modified  
to more or less work (i.e. no NeXTstep, no dsp, limited foreign code  
interface) as follows.  THIS WILL ONLY WORK FOR 030 MACHINES!!!   
There is no known fix for the 040 machines.

Make sure that the /usr/cl directory from 1.0 is backed up. Also save  
the /usr/lib/emacs/lisp/fi directory if you like that sort of thing.

After building a 2.0 system, re-install the /usr/cl directory.

Save the following program as fixlispheader.c:
=========================================================
#include <mach.h>
#include <sys/loader.h>
#include <sys/file.h>
#include <nlist.h>
/* This fixes the mach header of /usr/cl/build/static.o for release  
2.0 */
main()
{
	int fd;
	struct mach_header mh;
	struct nlist nl;

	fd = open("static.o", O_RDWR);
	read(fd, &mh, sizeof(mh));
	mh.cputype = CPU_TYPE_MC680x0;
	mh.cpusubtype = CPU_SUBTYPE_MC68030;
	lseek(fd, 0, L_SET);
	write(fd, &mh, sizeof(mh));

	lseek(fd, 1400832, L_SET);
	read(fd, &nl, sizeof(nl));
	nl.n_type = N_SECT | N_EXT;
	nl.n_sect = 1;
	lseek(fd, 1400832, L_SET);
	write(fd, &nl, sizeof(nl));
}
====================================================================

Compile this program: (i.e. "cc -o fixlispheader fixlispheader.c"),  
then in a shell as root:

	# cd /usr/cl/build
	# fixlispheader

This will destructively modify the static.o file so that it works  
with the 2.0 release.

Before doing a normal "config" operation to build the lisp image, the  
config file must be modified to not link in libNeXT and libdsp. Open  
/usr/cl/build/config and change line 679 from

	LDFLAGS = -lcrt0.o -u _NXEditorFilter -u _DSPAwaitData
to
	LDFLAGS = -lcrt0.o

Also change line 680 from

	LIBRARIES = -lNeXT_s -ldsp_s -lsys_s 

to
	LIBRARIES = -lsys_s 


After these modifications, run the configuration script as normal.

Dynamic foreign code loading is also broken: (load "foo.o") will not  
work. The workaround is to build a custom image (using the  
configuration script) with your code linked in. To do this, add your  
.o files to the LIBRARIES macro mentioned above. For example:

	LIBRARIES = /me/foo.o -lsys_s 


When running this image, use the lisp defforeign function as usual.

QA670