Re: [Gcl-devel] Re: gcl-2.6.8

[Camm Maguire]

Greetings!

Donald Winiecki <address@hidden> writes:

> Hi Camm,
>
> Have you had a chance to commit your most recent changes.  I'd like to do a 
> test build of what you think is
> the final CVS tree.
>

OK, my changes are in.

As some who've followed gcl for a while have observed, it has been a
goal of mine to offload shared functionality to well maintained
external libraries.  Hence gmp replacing the older native gcl mp code.
Likewise, I had thought that native object code relocation could be
offloaded to libbfd.  After tangling with this for years, and after
writing very complicated workarounds to extend to mips and alpha, and
after wrestling with the bfd inconsistencies regarding macho and the
wrappers that would be required, I've come to the conclusion that this
will not provide the support we were hoping for.  libbfd had extended
native object code relocation to m68k,arm,s390, and amd64, but many
targets never became supported, and newer targets (e.g. sh4) typically
did not work off the bat.  Furthermore, at least glancing at arm,
comparatively trivial custreloc modifications would extend support to
this target.  Finally, I've wound up learning more about this than I
had ever wanted, so its now easier to work with custreloc, as its much
simpler.

There are now three custreloc object formats supported --  coff,
macho, and elf.  These share a lot of code, and hopefully more in the
future.  elf support is currently i386 and sparc only, but I have
confidence that the other bfd targets will follow shortly, enabling
us to remove the binutils subtree.  For now, the tree remains in place
and is the default for supported elf targets as before.  macho
supports ppc, i386, and x86_64, and is the only option here.  coff is
windows/wine i386 only, and again the only option here.

The loaders make use of private copy on write mmaps by default.  This
can be redirected to gcl's native malloc and fread via
si::*load-using-fread*.  There does not appear to be much performance
difference, but in tight memory environments, using malloc should be
more robust.

gcl now builds under wine, at least using Debian linux.  Instructions
are in README.wine.  There is a workaround for a permanent wine bug --
their implementation of system() will never wait on unix binaries, so
we spawn a little msys process to read the compiler commands from a
file report the exit code when done.  There is a variable
si::*wine-detected* which should be set automatically, and in addition
to redirecting system, also removes the device from the compiled
pathnames, and uses the system directory as the temporary directory.
It would be nice if someone would now test a native (i.e. non-wine)
mingw build and try to construct a trial installer.

mac instructions are in README.macosx.  The xcode on various systems
is alas somewhat different.  This has been successfully tested on ppc
10.4, x86 10.5, and x86 and x86_64 10.6.  The 10.5 is tested using gcc
4.0, the default, and gcc 4.2 (yes they differ).  10.6 by default
detects itself as a 686 cpu.  This does not appear to be a bug in
config.guess, as the latest gmp source does likewise.  So the default
build is 32bit.  To get 64, use ./configure
--build=x86_64-apple-darwin10.4.0 ... as in the README.

The gmp tree has been upgraded to latest stable gmp4.  Minor patch
required to support default gcc 4.0 on 10.5, as the inline detection
supplied is failing.

Not merged into cvs head yet.

Feedback most appreciated.

Take care,

> Best,
>
> _don
>
> On Tue, Aug 3, 2010 at 5:06 PM, Camm Maguire <address@hidden> wrote:
>
>     Greetings!
>    
>     Matt Kaufmann <address@hidden> writes:
>    
>     > Cool!  Well done!
>     >
>     > By the way, I've been thinking about the pending ACL2/Debian problem,
>     > related to moving .cert files, and I have an idea for how to modify
>     > ACL2 to solve it.  I'm awaiting a reply on an email I sent a day ago
>     > to someone else before doing anything serious on it.
>     >
>    
>     Great!  Let me know when you're ready.
>    
>     I managed to get a 64bit mac build too.  A few issues with maxima I'm
>     chasing down now, but flawless acl2 certs.
>    
>     It appears we're getting close to a gcl release.  You might recall out
>     having used static builds in the past to enable 32bit linux machines
>     to use up to 3gig memory as opposed to the usual 1gig limit (imposed
>     by the load address of shared libraries.)  Warren told me at one time
>     that this was useful in getting the most out of 32bit, especially as
>     64bit comes with its own overhead of bigger pointers.  In addition,
>     the binary of course is completely portable.  Is this important to
>     support?  There appear to have been some libc developments which will
>     have to be worked around to get it working now.
>    
>     Take care,
>    
>     > -- Matt
>     >    Cc: address@hidden, address@hidden,
>     >          Donald Winiecki <address@hidden>
>     >    From: Camm Maguire <address@hidden>
>     >    Date: Wed, 28 Jul 2010 17:42:21 -0400
>     >    X-SpamAssassin-Status: No, hits=0.2 required=5.0
>     >    X-UTCS-Spam-Status: No, hits=-190 required=165
>     >
>     >    Greetings!  Just a heads up on the status.  Thanks to R. Krug's
>     >    machine, I have an (as yet uncommitted) patch which builds gcl on all
>     >    3 flavors of macs (ppc, x86 10.5, and x86 10.6) , and windows 
> emulated
>     >    under wine, which build maxima and acl2 passing all tests.  Will be
>     >    adding axiom to the test suite, then commit, then finalize 2.6.8.
>     >
>     >    The 10.6 build is 32bit at the moment.  It appears that this is a 
> hard
>     >    limit at the present time due to gcc miscompiling gmp in 64bits.
>     >
>     >    Donald, I think this patch will enable you to build natively under
>     >    windows too.  It would be great if we could test this when its ready
>     >    in a few days.  I have a few questions for you regarding paths and
>     >    windows installers.
>     >
>     >    I'll send out a note when the commit is in.
>     >
>     >    Take care,
>     >    --
>     >    Camm Maguire                                           address@hidden
>     >    
> ==========================================================================
>     >    "The earth is but one country, and mankind its citizens."  --  
> Baha'u'llah
>     >
>     >
>     >
>     >
>     >
>    
>     --
>     Camm Maguire                                       address@hidden
>     ==========================================================================
>     "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>    
>     _______________________________________________
>     Gcl-devel mailing list
>     address@hidden
>     http://lists.gnu.org/mailman/listinfo/gcl-devel
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah