[Openmcl-devel] new 0.14 binaries (finally!)

[Gary Byers]

On Wed, 25 Jun 2003, bryan o'connor wrote:

> > OpenMCL 0.14-030623
>
> a note about openmcl on 10.3/panther using gcc3.3 on a
> 32bit machine:
>
> - the only change needed for the kernel compilation was the
>    removal of --traditional-cpp.  i had to do the same with
>    some other software builds (for example, emacs).  i imagine
>    that they are deprecating the need for this across the
>    system, but i don't know that for sure.
>

I'm pretty sure that gcc3.3 has its own precompiled header mechanism;
"--traditional-cpp" was a workaround for the fact that Apple's
PCH mechanism rarely worked.

> - i was able to build the latest CVS sources (bootstrapping
>    from the latest public 0.14 build).
>
> - running the cocoa demo app works just fine.
>
> let me know if you have some specific code that you think
> might break and i can test it out for you.  i'll try to get
> access to one of the G5 test boxes if you want to test any
> 64bit/32bit problems.

I've had access to an old POWER3 system (basically a first-generation
PPC64 system) for the last few months.  There was some code in the
lisp kernel that assumed that a cache line was always 32 bytes wide;
correcting that assumption (and asking the OS for the size of data
cache lines) was all that was necessary to get the lisp running
as a 32-bit application under LinuxPPC, and (in theory) the same
should be true in OSX/Darwin.

If the OS is running in 64-bit mode, the block of "otherwise unused"
memory that the lisp tries to reserve on startup may conflict with
some library code or data.  The image-loading code in the lisp kernel
is supposed to recognize the case when a heap image is loaded into
a different memory configuration than it was saved from; it may take
a little longer to start up in that case.

Some versions of 64-bit Linux don't deliver exception information
to 32-bit applications correctly (I reported this and someone sent
a patch, but I'm not sure if that ever made it into the linuxpp64
tree.)  If any similar problems exist in OSX, it'd be good to identify
and report them as soon as possible.  (This would probably manifest
itself as an "unhandled exception" when the exception should have
been handled.)

Thanks!

>
> 							...bryan
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel