Re: [MIT-Scheme-devel] Attempted Clean-up of Mac OS X MIT Scheme Port

[Chris Hanson]

Aaron Hsu wrote:

Hi Aaron,

Sorry for the long delay on this reply.  I've finally made most of the
changes to address the problems you're having, which you can get from CVS.

> Before anything can really happen, I made sure my environment was
> setup up specifically. The reason for this is that I have still not
> found a decent way around the rather kudgy library detection used in
> the autoconf scripts. I had the most problems with postgresql and db
> not being detected. 

Hopefully this is better now.  The "--with-FOO" options now take
arguments to specify where the include/libs directories are, so that
"--with-libpq=/usr/local" will look in "/usr/local/include" and
"/usr/local/lib".

> Now, MacPorts doesn't install the binaries for postgresql in any
> reasonable location, but since I bypassed the PQ_INCLUDE detection
> used in the configure.ac file of the microcode, I decided not to worry
> about it. (A solution really ought to be found for that script that
> does not require a hard coded path like /usr/bin/pg_config.)

The configure script now looks for pg_config on the PATH.  Or you can
override using "--with-libpq" as above.

> There was no os-dependent configuration line in microcode/configure.ac
> for handling darwin needs, so in the patch below I have added the
> necessary MODULE_LDFLAGS options.

I've merged this change.

> MESSING WITH CMPAUXMD
> 
> By far the most annoying problem as yet has been with cmpauxmd. For
> some reason, make on Mac OS X does not properly handle the implicit
> rules for making .s files. What happens is that it reads the
> .SUFFIXES, finds .c listed, and then assumes that this is the target
> to use.

This is a bug in GNU make prior to version 3.81.  It's being stimulated
by some weird stuff in the Makefile that ought to work -- and does, in
make 3.81 -- but which isn't necessary for this compilation.  I've
restructured how the Makefile is generated to work around the problem.

> After making all of these changes, everything goes smoothly, except
> that the scheme compiler seems to have a --heap limit of 3148 or it
> fails to start. So -- and this is another unclean fix -- I altered
> etc/compile.sh and microcode/utabmd.sh to explicitely use a --heap
> size of 3000. This should probably be changed to use a settings
> defined ahead of time by the autoconf script, which should be user
> alterable through the configure script.

I think Taylor added patches to fix this problem.

> I don't know much about the limit for the heap size, but I notice that
> autoconf does look for a malloc.h file. Since Mac OS X provides
> malloc/malloc.h is that a different type of malloc that would be
> sufficient for use? I'm guessing not, from what I hear. I'm sure there
> ought to be a fix to this limited size problem, can anyone fill me in
> on what's going on?

This is unfortunately hard to fix, because the current implementation
wants a large block of memory below 0x04000000.  MacOS X apparently uses
that part of the address space for other things.  A similar problem
happens in some GNU/Linux distributions, and also on Windows systems.

For the time being you'll have to live with the restriction.  However,
there are two things that might help: (1) the next version of the
microcode will double the available heap, and (2) use of the C back end
to the compiler eliminates the restriction altogether, at the cost of
some performance.

If you can try out the newest CVS code, I'd appreciate it.

Chris