In article <HJSTEIN.96Mar11152948@blinky.cpaf.com> hjstein@blinky.cpaf.com
(Harvey J. Stein) writes:
I'm distressed by your difficult build process. One of the problems is
that Linux isn't *an* OS -- it's a loose collection of OS's. It's hard
for us to get out configure/build process slicked up for Linux because
there are a lot of different variants. Solaris, Irix, FreeBSD -- these
are all pretty consistent.
I don't see how my problems were Linux specific. The difficulties
lied in having little disk space and having little RAM (16meg).
I refer to the fact that your make(1) couldn't even find ./Makefile.
That is quite strange, and I do not have a failure model for it.
The
solution was to try to compile a dynamically linked, stripped version
without debugging. The problem was that getting the "-g" out of all
the calls to gcc, and getting the "-s" into the apropriate calls to
the linker was tricky - the "-g" was both on CFLAGS and on LDFLAGS,
and some links couldn't tolerate the "-s" flag. An additional hurdle
was that the INSTALL file mentioned "make CFLAGS=-O2 LDFLAGS=-s", but
this doesn't work, because as I said, some of the links need the
symbols.
I'd expect that someone trying to build a stripped version without
debugging would run into the same problems on any platform.
If you strip the binary, you will lose. The foreign-function interface
has to have that information to know how to call C funs from Scheme
(it has to be able to look up the address of a symol at run time).
The scsh image is big for a reason: you are getting a lot. A compiler,
a shell, a debugger, a bignum package, etc., etc. It's all there.
This wouldn't be a problem if all this junk would just lurk on disk
until you needed it, but it isn't. It's in the GC'd heap, so it gets
copied back and forth on each GC.
This is really too bad. It seems to make scsh unsuitable all those
little shell scripts and awk scripts that I have to write - the
overhead's just too high. It means that scsh can only be used for
large, long running applications, which I don't think is the intent.
It also means that all this code cannot be shared between multiple
running copies. So, is there any work being done on getting around
this - I saw something about getting the base system off the heap and
into code space. Is this being done? Any target date? What about a
porting to a version of scheme that includes a compiler - is any work
being done on this?
Well, the guys at NEC are developing a native-code compiler. I was up at
at Princeton on Thursday, and they keep assuring me it's coming along
real fine... I'm sure your children will live to see the day.
Other Schemes? I can think of two Texan ones that would make fine substrates.
Chez and guile are also options. But I'm not going to do it -- I'd rather
put the time in on designing and implementing multi-thread support, signal
handlers, porting scsh to the next release of Scheme 48 (0.41, now in beta).
So it would have to be someone else.
-Olin
|