gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl-2.6.8
Date: Fri, 15 Oct 2010 16:36:57 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings!

Tim Daly <address@hidden> writes:

>  Camm,
>
> I am trying to build ACL2 on Ubuntu.
> It keeps running out of allocation space.
> I used the configure parameters:
>
> configure --enable-vssize=65536*8 --enable-locbfd --disable-dynsysbfd
> --disable-statsysbfd
>           --enable-maxpage=1023*1024 --disable-xgcl --disable-tkconfig
>

The standard default sizes work to build acl2 on Debian, Ubuntu's
parent.  My hunch is that there is a system limit to the size of the
.data segment.  Look at ulimit -a, though gcl should try to override
this if possible.  Then look at kernel limits.  This is an sbrk
failure, and you can see the error code if you like by running under
strace -f -- bet its ENOMEM.

Please keep me posted.

Take care,

> The actual failing message is:
>
> [GC for 5011 CONTIGUOUS-BLOCKS pages...(T=13).GC finished]
>
> "Executing (si::sgc-on t)" [SGC on][SGC off][GC for 5011
> CONTIGUOUS-BLOCKS pages...
> Unrecoverable error: Can't allocate. Good-bye!
>
> Have you built ACL2 successfully?
> What configure parameters worked.
>
> Tim
>
> On 10/14/2010 2:23 PM, Camm Maguire wrote:
>> Greetings!
>>
>>
>> Tim Daly<address@hidden>  writes:
>>
>>>   Camm, this is failing with:
>>>
>>> cvs [checkout aborted]: cannot expand modules
>>>
>>> which seems to be a server permission problem:
>>>
>>> http://durak.org/sean/pubs/software/cvsbook/Checkouts_002fupdates-exit-with-error-saying-cannot-expand-modules.html
>>>
>> On one of the external debian machines at the moment:
>>
>> address@hidden:~$ cvs -z9 -q -d:pserver:address@hidden:/sources/gcl co -d 
>> gcl-2.6.8pre -rVersion_2_6_8pre gcl
>> cvs checkout: CVS password file /home/camm/.cvspass does not exist - 
>> creating a new file
>> U gcl-2.6.8pre/AC_FD_CC
>> U gcl-2.6.8pre/AC_FD_MSG
>> U gcl-2.6.8pre/COPYING.LIB-2.0
>> U gcl-2.6.8pre/ChangeLog
>> ....
>>
>>
>> Could this be some local problem?
>>
>> Take care,
>>
>>
>>> On 8/23/2010 1:07 PM, Camm Maguire wrote:
>>>> Greetings!
>>>>
>>>> cvs -z9 -q -d:pserver:address@hidden:/sources/gcl co -d gcl-2.6.8pre 
>>>> -rVersion_2_6_8pre gcl
>>>>
>>>> Might be nice to see if we can get axiom working under wine.  See
>>>> README.wine if interested.
>>>>
>>>> Take care,
>>>>
>>>> Tim Daly<address@hidden>   writes:
>>>>
>>>>> Ok. I did
>>>>> cvs -z3 -d... co gcl
>>>>> ./configure
>>>>> make
>>>>>
>>>>> and it fails. As I recall I need to check out something like
>>>>> gcl-2.6.8pre or something but I can't remember the correct
>>>>> tag and I can't find it in CVS.
>>>>>
>>>>> What is the magic cvs command again?
>>>>>
>>>>> Tim
>>>>>
>>>>> Camm Maguire 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]