[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] Attempted Clean-up of Mac OS X MIT Scheme Port
From: |
Chris Hanson |
Subject: |
Re: [MIT-Scheme-devel] Attempted Clean-up of Mac OS X MIT Scheme Port |
Date: |
Fri, 12 Jan 2007 14:35:45 -0500 |
User-agent: |
Icedove 1.5.0.9 (X11/20061220) |
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
- Re: [MIT-Scheme-devel] Attempted Clean-up of Mac OS X MIT Scheme Port,
Chris Hanson <=