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

[Camm Maguire]

Greetings!  Thanks!  Please cvs update and try again.

Take care,

Donald Winiecki <address@hidden> writes:

> Hi Camm,
>
> Bad news.  GCL 268pre fails during make on my WinXP machine.  Here are the 
> last few lines of the log -- all I
> can copy from MSYS.
>
> ranlib libgclp.a
> cp init_pre_gcl.lsp.in init_pre_gcl.lsp.tmp
> cat init_pre_gcl.lsp.tmp | sed \
>         -e "address@hidden@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
>         -e "address@hidden@#`cat ../minvers | cut -f2 -d.`#1" \
>         -e "address@hidden@#`cat ../minvers | cut -f1 -d.`#1" \
>         -e "address@hidden@#`cat ../majvers`#1" \
>         -e "address@hidden@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -pipe 
> -fno-zero-initialized-in-bss
> -mms-bitfields -march=i386 \"#1" \
>         -e "address@hidden@#\"gcc  -o \"#1" \
>         -e "address@hidden@#\" ../o/firstfile.o  -lpre_gcl -lm -lmingwex  
> -lreadline -lwsock32  -lgclp ../o/
> lastfile.o\"#1" \
>         -e "address@hidden@#\"-O3 \"#1" \
>         -e "address@hidden@#\"-O\"#1" \
>         -e "address@hidden@#\"init_pre_gcl.lsp\"#1" >init_pre_gcl.lsp
> touch raw_pre_gcl_map
> gcc  -o raw_pre_gcl.exe ../o/mingwin.o ../o/mingfile.o -L.  -Wl,-Map 
> raw_pre_gcl_map ../o/firstfile.o 
> -lpre_gcl -lm -lmingwex  -lreadline -lwsock32  -lgclp ../o/lastfile.o
> PATH=/usr/bin:$PATH cc msys.c -o msys # Unix binary if running wine
> /bin/sh: cc: command not found
> make[1]: *** [msys] Error 127
> make[1]: Leaving directory `/c/_cvs/gcl268pre/unixport'
> make: *** [unixport/saved_pre_gcl] Error 2
>
> _don
>
> On Wed, Aug 4, 2010 at 4:35 PM, Camm Maguire <address@hidden> wrote:
>
>     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
>

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