🚀 go-pugleaf

Well I just upgraded to NeXTstep 3.0 and as expected my copy of ACL 3.1
no longer works.  It fails with the following message:

	Minor versions don't match in /usr/shlib/libNeXT_s.C.shlib
	This image cannot be executed

Now I assume that this is occurring because Franz built ACL 3.1 to use a
dynamic library (rather than producing a large statically linked executable).

Presumably re-installing ACL 3.1 under NS 3.0 won't help because source
or object files of the lisp kernel aren't available to allow re-linking with
the new version of libNeXT_s.C.shlib.

Another possibility which occurred to me was to invoke ACL 3.1 with a
script that substituted the NS 2.1 version of libNeXT_s.C.shlib.  But that
might cause poblems for other processes that require the 3.0 version
of libNeXT_s.C.shlib.

Then I wondered if I could zap the libNeXT_s.C.shlib version number in the
ACL 3.1 executable so it would match the NS 3.0 libNeXT_s.C.shlib.  Assuming
this could be done, the hope is that ACL 3.1 would work with the NS 3.0 version
of the library.  Is this worth trying?  If so, how would I determine the NS 3.0
version number and substitute it in the ACL 3.1 executable?

If my assumption that ACL 3.1 won't work under NS 3.0 because of its use
of a dynamic library, what lesson can developers learn from this.  Should
they avoid using dynamic libraries?  Are there ways of using dynamic libraries
which avoid the problem?

Of course Franz could just relink ACL 3.1 under NeXTstep 3.0 and release
an update.  However they apparently don't plan to do this because they
are applying all their resources to getting ACL 4.1 out the door.
I guess that it might not be as simple as just relinking ACL 3.1 under
NS 3.0 for them - they would need to put it thru quality assurance to
check that it worked correctly with the NS 3.0 version of the library.
Given that they are close with ACL 4.1, I can understand why they wouldn't
want to do this.

Problem is that all of us ACL 3.1 users who have moved to NS 3.0 are
without a running lisp until ACL 4.1 appears (and they pay for it).
Now Bill Vrotney has mailed to this list that "Some wonderful guys who
wish to remain anonymous have come up with a simple fix for ACL 3.1.20
work under NeXTstep 3.0 ..."  Apparently their fix gets ACL going but
not the Objective C interface.  Bill has asked them for the fix so
he could post details, but so far nothing has been posted.

Well what one group of wonderful guys can do another can do too.
My suggestion is that we work together to try and come up with a
fix.  Anyone interested?

Peter Milne	(milne@csis.dit.csiro.au)