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 "s...@li-vers@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
-e "s...@li-extvers@#`cat ../minvers | cut -f2 -d.`#1" \
-e "s...@li-minvers@#`cat ../minvers | cut -f1 -d.`#1" \
-e "s...@li-majvers@#`cat ../majvers`#1" \
-e "s...@li-cc@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
-fno-zero-initialized-in-bss -mms-bitfields -march=i386 \"#1" \
-e "s...@li-ld@#\"gcc -o \"#1" \
-e "s...@li-ld-libs@#\" ../o/firstfile.o -lpre_gcl -lm -lmingwex
-lreadline -lwsock32 -lgclp ../o/lastfile.o\"#1" \
-e "s...@li-opt-three@#\"-O3 \"#1" \
-e "s...@li-opt-two@#\"-O\"#1" \
-e "s...@li-init-lsp@#\"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 <c...@maguirefamily.org> wrote:
> Greetings!
>
> Donald Winiecki <dwinie...@boisestate.edu> 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 <c...@maguirefamily.org>
> wrote:
> >
> > Greetings!
> >
> > Matt Kaufmann <kaufm...@cs.utexas.edu> 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: desti...@mac.com, gcl-devel@gnu.org,
> > > Donald Winiecki <dwinie...@boisestate.edu>
> > > From: Camm Maguire <c...@maguirefamily.org>
> > > 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
> c...@maguirefamily.org
> > >
> ==========================================================================
> > > "The earth is but one country, and mankind its citizens." --
> Baha'u'llah
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Camm Maguire
> c...@maguirefamily.org
> >
> ==========================================================================
> > "The earth is but one country, and mankind its citizens." --
> Baha'u'llah
> >
> > _______________________________________________
> > Gcl-devel mailing list
> > Gcl-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/gcl-devel
> >
>
> --
> Camm Maguire c...@maguirefamily.org
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
