Hi Camm,
gcl.info is included in the current download for info files
(ftp://ftp.gnu.org/pub/gnu/gcl/gcl.info.tgz).
However:
1. Neither gcl-si.info or gcl-tk.info is in the current download for
info files, and
2. When the current download for info files is unpacked, only gcl.info
is unpacked. A
Hi Camm,
All worked well with the info files when first set up 2.6.8 pre on my
machine last August.
I don't believe it is the build but rather the files themselves --
they appear to be munged on the server. When I copy the info files I
archived last summer into an appropriate directory path, the
Hi Camm,
All worked well with the info files when first set up 2.6.8 pre on my
machine last August.
I don't believe it is the build but rather the files themselves --
they appear to be munged on the server. When I copy the info files I
archived last summer into an appropriate directory path, the
~~m
> >
> > -Original Message-
> > From: Jovan Trujillo
> > Sender: gcl-devel-bounces+dwiniecki=boisestate@gnu.org
> > Date: Wed, 2 Mar 2011 18:40:02
> > To:
> > Subject: [Gcl-devel] Re: GCL268pre (still) fails in ANSI build on WinX
Hi Donald,
On my WinXP system with the latest version on mingw (gcc 4.5.0) and
msys 1.0 I run:
configure --enable-ansi --prefix="/local/gcl" >configure.log 2>&1
make >& make.log
./unixport/saved_ansi_gcl.exe
and get the gcl prompt. I have problems with running "(describe
'cons)" and get the erro
The same problem happens with:
(%i1) submatrix(foo);
Maxima encountered a Lisp error:
Error in PROGN [or a callee]: Caught fatal error [memory may be damaged]
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%i2) submatrix(foo);
Segmentation fault
Stefano
2011/2/16 Leo T Butler
> Sure, the first problem is that gcl complains that the package
> user is undefined; if I add (defpackage :user), then compilation proceeds
> until I get
>
> ;- Compiling module "declarations"
> ; - Loading binary file "binary-gcl/lmdcls.o"
> ;; Loading binary-gcl
I just built gcl from HEAD, which worked fine on debian testing.
> What does not work at all for me is building Maxima HEAD from gcl.
> Perhaps Camm is using a custom build script for Maxima, but our
> build process barfs immediately.
>
>
> Leo
>
>
Well, I've built gcl from head, but maxima is the
Camm Maguire writes:
| Greetings, and thanks! I agree, but can it wait post 2.6.8?
Hi Camm,
I would have liked it to be in 2.6.8. However, if you believe it is too
risky when so close to a release, then, well, I'll wait :-)
Thanks!
-- Gaby
___
Gc
Hi Camm,
One more issue/request: At the moment compiler::*ld* does not -just-
designate the linker. It contains also flags (and arguments) to the
linker proper. I believe that should be splitted as follows:
-- compiler::*ld*: a string that designates the name of the linker
-- compiler::*
Greetings!
"Richard E. Harke" writes:
> ia64 hardware renames registers after a subroutine call.
> (registers 0-31 do not get renamed) The alloc
> instruction specifies how many registers to protect. The first
> one past that number will be renamed r32 after the next call.
> In this case r33 is
ia64 hardware renames registers after a subroutine call.
(registers 0-31 do not get renamed) The alloc
instruction specifies how many registers to protect. The first
one past that number will be renamed r32 after the next call.
In this case r33 is saving some status related to renaming,
r34 is savi
Greetings!
Raymond Toy writes:
> On 11/8/10 11:49 AM, Camm Maguire wrote:
>> Greetings! OK, that's enough for me -- GCL's migration to LGPLv3
>> will not occur until maxima and acl2 choose to do so as well, if
>> ever.
>
> I may be mistaken. Looking through the maxima archives, there's a
> th
Greetings! Great to hear from you -- was just arguing with myself
whether I was going to tackle this or not.
Some unrelated good news -- hppa32 is finished and testing, and will
be committed shortly.
"Richard E. Harke" writes:
> Well, steps one and two were easy enough.
>
> I have been reading
Well, steps one and two were easy enough.
I have been reading documentation and looking
through existing code but i think it is time to
ask some questions. First, maybe, some more
background. If this is to replace the use of
dlopen, what is the advantage?
As a replacement for dlopen, I assume tha
On 11/8/10 11:49 AM, Camm Maguire wrote:
> Greetings! OK, that's enough for me -- GCL's migration to LGPLv3
> will not occur until maxima and acl2 choose to do so as well, if
> ever.
I may be mistaken. Looking through the maxima archives, there's a
thread about GPLv3 from June 1, 2008. It seem
Hi, Camm --
By the way, it's not particularly important to me that we distribute a
GCL binary with ACL2. If we don't, then I don't see how the GCL
license has any effect on ACL2 licensing or distribution (please
correct me if I'm missing something).
Thanks --
Matt
Cc: gcl-devel@gnu.org, Donal
Greetings! OK, that's enough for me -- GCL's migration to LGPLv3
will not occur until maxima and acl2 choose to do so as well, if
ever.
IMHO, I would encourage both projects to consider this, as the GPLv3
is actually more flexible in many circumstances. For example, were
these systems GPLv3, my
I believe that ACL2 is GPLv2 in that same sense (except we do
occasionally put up CCL images as well).
-- Matt
X-Injected-Via-Gmane: http://gmane.org/
From: Raymond Toy
Date: Mon, 08 Nov 2010 06:28:10 -0500
X-Gmane-NNTP-Posting-Host: user-0c99ag2.cable.mindspring.com
X-detected-ope
On 11/5/10 9:52 AM, Camm Maguire wrote:
> Greetings, and thanks so much for this!
>
> I've been asked to query -- are there any GPLv2 only projects using
> GCL? If so, please now so state.
I think maxima is GPLv2 only. GCL isn't the only Lisp that can be used
with maxima, but it has historicall
Greetings, and thanks so much for this!
I've been asked to query -- are there any GPLv2 only projects using
GCL? If so, please now so state.
It should be noted here that in some respects the GPLv3 is actually
more permissive than the v2, according to some irc discussion on
debian-devel. Details
Greetings, and thanks so much for your helpful feedback!
"Andrey G. Grozin" writes:
> On Thu, 4 Nov 2010, Camm Maguire wrote:
>> But this leaves the question of the gmp4 directory. Tim once told me
>> he would have to include it if I removed it, for the convenience
>> reasons you mention above.
On Thu, 4 Nov 2010, Camm Maguire wrote:
But this leaves the question of the gmp4 directory. Tim once told me
he would have to include it if I removed it, for the convenience
reasons you mention above. I'm not really sure what I think here. A
lisp system must implement mp, so it is not illogica
Camm and all,
It is possible that your correspondent is referring to section 6 of
GPL3 (http://www.opensource.org/licenses/gpl-3.0.html), text of which
is included below (see 6.a.) (it appears that all except section 3 of
GCL3 is telegraphed through LGPL3 -- see section 1 of LGPL3
[http://www.open
Camm Maguire writes:
| Greetings!
|
| Gabriel Dos Reis writes:
|
| > One question: does compiler::*default-system-p* still control whether
| > the built GCL uses a copy of its C header file from its image or from
| > its system directory? It is extremely convenient to be able to use GCL,
| >
Greetings! I've received a thoughtful reply claiming that the LGPLv3
is more onerous than v2 in that it obligates all distributors to
provide physical media, and not simply provide electronic
distribution. I cannot find this text -- anyone know for sure?
Take care,
Donald Winiecki writes:
> G
Camm Maguire writes:
[...]
| > [...]
| >
| > | Corrections/additions to this table most welcome. We should probably
| > | include similar in the release notes and on the web page.
| >
| > One question: does compiler::*default-system-p* still control whether
| > the built GCL uses a copy of its
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings! Looking like the following:
> |
> | Debian/Ubuntu: (mips mipsel mipsel64 x86 x86_64 ia64 hppa sh4 ppc ppcspe
> alpha sparc
> | sparc64 hurd kfreebsd-86 kfreebsd-amd64 armel s390)
> |
> | (Now with na
Camm Maguire writes:
| Greetings! Looking like the following:
|
| Debian/Ubuntu: (mips mipsel mipsel64 x86 x86_64 ia64 hppa sh4 ppc ppcspe
alpha sparc
| sparc64 hurd kfreebsd-86 kfreebsd-amd64 armel s390)
|
| (Now with native object relocation on win32, all macosx, and all the
Camm Maguire writes:
| Greetings!
|
| Gabriel Dos Reis writes:
|
| > I believe you need something like:
| >
| > LARGE_INTEGER ticks;
| > if (QueryPerformanceFrequency(&ticks)) {
| >/* high resolution available. /
| >const double micros = 1.0e6/ticks.QuadPart;
| >
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings! Trying wine again: after an ssvn update, or fresh checkout
> | per your instructions:
> |
> | ../oa.trunk/configure --with-lisp=gcl --build=mingw32
> | configure: error: cannot find sources (src/Makefile.pamphlet) in
Greetings!
Gabriel Dos Reis writes:
> I believe you need something like:
>
> LARGE_INTEGER ticks;
> if (QueryPerformanceFrequency(&ticks)) {
>/* high resolution available. /
>const double micros = 1.0e6/ticks.QuadPart;
>LARGE_INTEGER snapshot;
>QueryPerfo
Camm Maguire writes:
[...]
| OK, this is in now. Repeated (si::save-sytem ...) calls should not
| grow the file image size perforce.
OK, thanks!
-- Gaby
___
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
Camm Maguire writes:
| Greetings! There are a few files with \r\n line endings -- win32 has
| no problem with standard unix \n, right?
It depends on what you are doing. Do those files need to be in text
mode or can you read and write them in binary mode (even if they will
contain text, if view
Camm Maguire writes:
| Greetings! Trying wine again: after an ssvn update, or fresh checkout
| per your instructions:
|
| ../oa.trunk/configure --with-lisp=gcl --build=mingw32
| configure: error: cannot find sources (src/Makefile.pamphlet) in ../oa.trunk
or ..
That is a silly error from may p
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings!
> |
> | Gabriel Dos Reis writes:
> |
> | > Camm Maguire writes:
> | >
> | > | Greetings, and thanks! Should be fixed now. Please let me know if
> | > | problems persist.
> | >
> | > Everything builds fine this tim
Camm Maguire writes:
| Greetings!
|
| Gabriel Dos Reis writes:
|
| > Camm Maguire writes:
| >
| > | Greetings!
| > |
| > | Gabriel Dos Reis writes:
| > |
| > | > Camm Maguire writes:
| > | >
| > | > | Greetings, and thanks! Should be fixed now. Please let me know if
| > | > | problems p
Greetings! There are a few files with \r\n line endings -- win32 has
no problem with standard unix \n, right?
Take care,
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings!
> |
> | Gabriel Dos Reis writes:
> |
> | > Camm Maguire writes:
> | >
> | > | Greetings, and thanks! S
Greetings! Trying wine again: after an ssvn update, or fresh checkout
per your instructions:
../oa.trunk/configure --with-lisp=gcl --build=mingw32
configure: error: cannot find sources (src/Makefile.pamphlet) in ../oa.trunk or
..
Take care,
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings!
> |
> | Gabriel Dos Reis writes:
> |
> | > Camm Maguire writes:
> | >
> | > | Greetings, and thanks! Should be fixed now. Please let me know if
> | > | problems persist.
> | >
> | > Everything builds fine this tim
Camm Maguire writes:
| Greetings!
|
| Gabriel Dos Reis writes:
|
| > Camm Maguire writes:
| >
| > | Greetings, and thanks! Should be fixed now. Please let me know if
| > | problems persist.
| >
| > Everything builds fine this time around. Hurray!
| >
|
| Great!
|
| 1) Any microsecond clo
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings, and thanks! Should be fixed now. Please let me know if
> | problems persist.
>
> Everything builds fine this time around. Hurray!
>
Great!
1) Any microsecond clock function on windows like gettiemofday()?
2) One ot
Camm Maguire writes:
| Greetings, and thanks! Should be fixed now. Please let me know if
| problems persist.
Everything builds fine this time around. Hurray!
Thanks,
-- Gaby
___
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailma
Greetings, and thanks! Should be fixed now. Please let me know if
problems persist.
Take care,
Gabriel Dos Reis writes:
> On Mon, Nov 1, 2010 at 10:25 AM, Camm Maguire wrote:
>
> Hi Camm,
>
>> Here is how the raw_gcl.exe pathname is determined, which is not
>> related to the *system-director
Greetings!
David Daney writes:
> On 11/01/2010 09:24 AM, Camm Maguire wrote:
>> Greetings! Executing personality() with the ADDR_NO_RANDOMIZE bit set,
>> and re-executing via execve, should yield a process with traditional
>> contiguous brk() addresses appended to the .data segment, independent
On Mon, Nov 1, 2010 at 10:25 AM, Camm Maguire wrote:
Hi Camm,
> Here is how the raw_gcl.exe pathname is determined, which is not
> related to the *system-directory* setting. In general, it should
> produce the truename of the current directory:
You are absolutely right. However, it looks like
Greetings!
Gabriel Dos Reis writes:
> On Fri, Oct 29, 2010 at 8:24 PM, Camm Maguire wrote:
>> Greetings! P.S. Would be great if someone else could confirm before
>> release
>
> Hi Camm,
>
> I did the following:
>
> 1. `make clean' in the local tree
> 2. update local copy of CVS gcl-
Camm Maguire writes:
| Greetings!
|
| My apologies -- one small change required in the open axiom
| src/lisp/Makefile -- comment out the cp of rsym.exe, which is now
| obsolete. (Perhaps make it conditional on the file being present, to
| interwork with earlier versions.)
Hi Camm,
Thanks for
Greetings!
My apologies -- one small change required in the open axiom
src/lisp/Makefile -- comment out the cp of rsym.exe, which is now
obsolete. (Perhaps make it conditional on the file being present, to
interwork with earlier versions.)
fricas builds too, but with the above change, and a manu
On Fri, Oct 29, 2010 at 8:24 PM, Camm Maguire wrote:
> Greetings! P.S. Would be great if someone else could confirm before
> release
Hi Camm,
I did the following:
1. `make clean' in the local tree
2. update local copy of CVS gcl-2.6.8pre
3. build GCL
4. install GCL
5. make cle
Greetings! P.S. Would be great if someone else could confirm before
release
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Guess I should try fricas.
>
> Hi Camm,
>
> That is great news!
> Did you have to patch locally GCL or is current trunk (2.6.8pre) all it
> takes?
>
> In prin
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Guess I should try fricas.
>
> Hi Camm,
>
> That is great news!
> Did you have to patch locally GCL or is current trunk (2.6.8pre) all it
> takes?
>
Current cvs branch.
> In principle, you should be able to build FriCAS nativel
Camm Maguire writes:
| Guess I should try fricas.
Hi Camm,
That is great news!
Did you have to patch locally GCL or is current trunk (2.6.8pre) all it
takes?
In principle, you should be able to build FriCAS natively on Windows
because it derives from axiom.build-improvements, but I cannot guar
"Maciej W. Rozycki" writes:
> On Tue, 26 Oct 2010, Camm Maguire wrote:
>
>> > Why doesn't _IO_getc get a stub on mips64, like say _setjmp?
>> >
>> > readelf -a saved_ansi_gcl |grep IO_getc
>> > 2812: 472 FUNCGLOBAL DEFAULT UND
>> > _io_g...@glibc_2.0 (2)
>> > 15315: 0
Given recent information posted by Camm, I don't see a special reason
to not move to LGPLv3, as that wouldn't encroach on users of
Axiom-family tools.
But that's just me and if there are good reasons to not move this way,
perhaps not assigning copyright to FSF would also be an appropriate
move to
Greetings!
Gabriel Dos Reis writes:
> Donald Winiecki writes:
>
> | A change to the most recent licenses will make things consistent with
> | FSF's current way of thinking about open source, though more
> | aggressive developers seem to think it's restrictive. Given the
> | typical users and u
Donald Winiecki writes:
| A change to the most recent licenses will make things consistent with
| FSF's current way of thinking about open source, though more
| aggressive developers seem to think it's restrictive. Given the
| typical users and usual applications of GCL, this may not be an issue
"Richard E. Harke" writes:
> On Friday 27 August 2010 02:38:23 pm you wrote:
>> Greetings! We had discussed some time ago native object relocation in
>> gcl on ia64, in the context of axiom support. I've recently
>> implemented an overhaul of this feature, supporting custom (non-bfd)
>> relocat
Greetings, and thanks so much!
Nick Clifton writes:
> Hi Camm,
>
>> Greetings! I can't seem to find documentation anywhere on the sparc64
>> R_SPARC_OLO10 reloc, sometimes reported as a R_SPARC_LO10 and a
>> R_SPARC_13.
>
> I think that R_SPARC_0LO10 and R_SPARC_LO10 are subtly different...
>
>
Greetings!
Camm Maguire writes:
> Thanks.
>
> Why doesn't _IO_getc get a stub on mips64, like say _setjmp?
>
> readelf -a saved_ansi_gcl |grep IO_getc
> 2812: 472 FUNCGLOBAL DEFAULT UND _io_g...@glibc_2.0
> (2)
> 15315: 472 FUNCGLOBAL DEFAULT
Greetings! OK just checked in gmp5 support onto the 2.6.8pre branch.
Separately, perhaps you might be able to tell me why on an old
sicortex gentoo box (mips64) I get the following:
gcc -o raw_ansi_gcl -L. -Wl,-Map raw_ansi_gcl_map -lansi_gcl -lX11-lm
-lgmp -lreadline -lc -lgclp
/.r
Greetings!
David Daney writes:
> On 10/25/2010 02:32 PM, Camm Maguire wrote:
>> Greetings! Can gdb be made to work on mips64?
>>
>
> You have to have a 64-bit toolchain.
>
> Then something like this (untested):
>
> CC='mips64-linux-gnu -mabi=64' configure --host=mips64-linux
> --target=mips64-l
Greetings, and thanks so much for this and the kernel fix!
I've committed a little test which hopefully will enable trapping
these signals when the kernel fix is in place:
--- o/sgbc.c1 Oct 2010 19:15:40 - 1.9.4.1.2.12.6.1.2.1.6.4
+++ o/sgbc.c25 Oct 2010 19:46:35 -
@@ -1146,
Greetings! I can't seem to find documentation anywhere on the sparc64
R_SPARC_OLO10 reloc, sometimes reported as a R_SPARC_LO10 and a
R_SPARC_13. I know there is a special addend encoded in the reloc
type. Can you explain to me or point out to me how this reloc is
supposed to work?
Take care,
Thanks! I'm happy to know about si::stat, which although not defined
in my copy of GCL 2.6.7, is actually defined in the build of GCL
2.6.8pre that you recently made for me. I think I can get by fine; if
si::stat is defined, I'll insist that it return a non-nil value before
truename is called.
T
Greetings!
I've wrestled with this a bit in 2.7.0. I must confess I do not
really understand the lisp spec on these issues at all. There seems
to be considerable lattitude to implement what looks reasonable.
Truename must throw an error if links cannot be traversed or
directories cannot be "cd'e
Greetings!
David Daney writes:
> On 10/21/2010 09:19 AM, David Daney wrote:
>> On 10/20/2010 02:31 PM, Camm Maguire wrote:
>>> Greetings!
>>>
>>> Does this suffice?
>>>
>>> (sid)c...@gabrielli:~/maxima-5.22.1/tests$ uname -a
>>> Linux gabrielli 2.6.35.4-dsa-octeon #1 SMP Fri Sep 17 21:15:34 UTC
Greetings!
David Daney writes:
> On 10/20/2010 02:31 PM, Camm Maguire wrote:
>> Greetings!
>>
>> Does this suffice?
>>
>> (sid)c...@gabrielli:~/maxima-5.22.1/tests$ uname -a
>> Linux gabrielli 2.6.35.4-dsa-octeon #1 SMP Fri Sep 17 21:15:34 UTC 2010
>> mips64 GNU/Linux
>> (sid)c...@gabrielli:~/m
Greetings!
Does this suffice?
(sid)c...@gabrielli:~/maxima-5.22.1/tests$ uname -a
Linux gabrielli 2.6.35.4-dsa-octeon #1 SMP Fri Sep 17 21:15:34 UTC 2010 mips64
GNU/Linux
(sid)c...@gabrielli:~/maxima-5.22.1/tests$ cat /proc/cpuinfo
system type : CUST_WSX16 (CN3860p3.X-500-EXP)
proces
Greetings!
David Kuehling writes:
>> "Camm" == Camm Maguire writes:
>
>> Greetings! What is wrong with this stub attempting a jump to contents
>> of register $t0?
>
>> (gdb) p/x *(ul *)0x1094...@4 $3 = {0x3c080077, /*lui t0,0x77*/
>> 0x2508a170, /*addui t0,t0,0xa170*/ 0x8d08a288, /*lw t0,-
Greetings!
David Daney writes:
> On 10/15/2010 10:11 AM, Camm Maguire wrote:
>> Greetings! What is wrong with this stub attempting a jump to contents
>> of register $t0?
>>
>> (gdb) p/x *(ul *)0x1094...@4
>> $3 = {0x3c080077, /*lui t0,0x77*/
>>0x2508a170, /*addui t0,t0,0xa170*/
>>
Greetings!
Tim Daly 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 --d
Greetings! What is wrong with this stub attempting a jump to contents
of register $t0?
(gdb) p/x *(ul *)0x1094...@4
$3 = {0x3c080077, /*lui t0,0x77*/
0x2508a170, /*addui t0,t0,0xa170*/
0x8d08a288, /*lw t0,-23928(t0) */
0x108 /* jr t0*/ }
(gdb) c
Program received signal SI
Greetings!
Where can I get gmp5? Does anyone know why it is not in Debian
unstable yet?
Take care,
Tim Daly writes:
> Camm, FYI -- Tim
>
> Original Message
> Subject: Re: Axiom for Gentoo
> Date: Mon, 11 Oct 2010 20:02:40 +0200
> From: Thomas Kahle
Greetings!
David Daney writes:
>> On other machines with a .plt (e.g. alpha), I don't leave the gp at
>> its 'canonical' value, but rather set it to a mini-table I craft at
>> the end of the code to be loaded. I then populate this .got
>> accordingly. The _setjmp address I use is the address o
[ Andreas, please see bottom -- thanks! ]
Greetings!
David Daney writes:
> On 09/22/2010 02:40 PM, Camm Maguire wrote:
>> Greetings!
>>
>> David Daney writes:
>>
>>> On 09/20/2010 12:44 PM, Camm Maguire wrote:
David Daney writes:
> PLT support works with the n32 ABI (with new t
Greetings!
gcl has several modes for native object relocation, implemented via
configure switches:
--enable-statsysbfd -- use the system installed static bfd library,
path probed at configure time using standard environment variables
--enable-dynsysbfd -- use the system installed dynamic bfd l
Hi, Camm --
I just did a quick check, and I didn't notice any "bad plist" sort of
error in the 7 GCL-based ACL2 regression logs I looked at that
occurred since installing that new ACL2 thingamobob in, I think, late
March. That's not a lot of runs runs, so I'm not sure what kind of
proof we have h
Greetings!
Matt Kaufmann writes:
> That's really great news! This "Bad plist" error may have been the
> only unreliable aspect of GCL that I've encountered in many years, and
> it was frustrating at times.
>
Good to hear this may be of value.
>>> If you happen to
>>> have any old binary test
That's really great news! This "Bad plist" error may have been the
only unreliable aspect of GCL that I've encountered in many years, and
it was frustrating at times.
>> If you happen to
>> have any old binary test case lying around, try running it without
>> fast-links set, and then with (si::us
Greetings!
Regarding this old issue which has suffered from exacerbating
irreproducibility -- I think I might have fixed it. If you happen to
have any old binary test case lying around, try running it without
fast-links set, and then with (si::use-fast-links
nil)(si::use-fast-links t). If this
Greetings!
David Daney writes:
> On 09/20/2010 12:44 PM, Camm Maguire wrote:
>> David Daney writes:
>>
>>> PLT support works with the n32 ABI (with new toolchains). Can you use that?
>>
>> -mabi=n32 -mplt still seems to generate a .MIPS.stubs section
>> requiring canonical gp register settin
David Daney writes:
> On 09/17/2010 01:44 PM, Camm Maguire wrote:
>> Greetings!
>>
>> David Daney writes:
>>
>>> On 09/17/2010 07:16 AM, Camm Maguire wrote:
Greetings! Is there anyway to load a known 64bit number into a given
register in two instructions?
>>>
>>> Not in the general ca
Greetings!
David Daney writes:
> On 09/17/2010 07:16 AM, Camm Maguire wrote:
>> Greetings! Is there anyway to load a known 64bit number into a given
>> register in two instructions?
>
> Not in the general case where the value of the 64-bit number is
> unconstrained...
>
>> Said number is guaran
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> [...]
>
> | > Camm, what are the instructions to build and test GCL under wine?
> | >
> |
> | This is the README.wine file:
>
> Hi Camm,
>
> Thanks for the instructions. My box is a x86_64 running openSUSE-11.2.
> I don't think th
Gabriel Dos Reis writes:
| Camm Maguire writes:
|
| [...]
|
| | In any case, I've committed same or equivalent, and I get a working
| | link image now. Hope you do too.
|
| Hi Camm,
|
| There is still a problem. The LINK (for OpenAxiom) failed with this:
|
| gcc: ../o/firstfile.o: No su
Greetings!
Following your suggestion, I've managed to get the following working
in a readelf like manner, i.e. without bfd:
i386, amd64, alpha, mips, s390, m68k, arm, sparc, ppc, sh4
I'll attack ia64 and hppa when time permits.
I have one question re: mips and alpha. mips appears to be the o
Greetings!
Tim Daly writes:
> (defun compfail (parts0 parts1)
> (let ((same t))
>(loop for p0 in parts0 for p1 in parts1
> while same
> (setq same (eq p0 p1)
>
(compile 'compfail)
Take care,
>
> ___
> Axiom-developer mailing list
Camm Maguire writes:
[...]
| In any case, I've committed same or equivalent, and I get a working
| link image now. Hope you do too.
Hi Camm,
There is still a problem. The LINK (for OpenAxiom) failed with this:
gcc: ../o/firstfile.o: No such file or directory
Correctable error: (SYSTEM "g
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> | Greetings!
> |
> | Gabriel Dos Reis writes:
> |
> | > Camm Maguire writes:
> | >
> | > [...]
> | >
> | > | > Camm, do you think it is possible to make --disable-tk --disable-tcl
> | > | > entirely disabling linking with tcl/tk
Camm Maguire writes:
| Greetings!
|
| Gabriel Dos Reis writes:
|
| > Camm Maguire writes:
| >
| > [...]
| >
| > | > Camm, do you think it is possible to make --disable-tk --disable-tcl
| > | > entirely disabling linking with tcl/tk?
| > | >
| > |
| > | OK --enable-tcltk is now a configure sw
Greetings!
Gabriel Dos Reis writes:
> Hi Camm,
>
> Camm Maguire writes:
>
> [...]
>
> | > | Finally, your axiom configure does not propagate the CC setting, so
> | > | bsdsignal etc are compiled as elf by the normal system gcc.
> | >
> | > That is odd. I'll look into that and update you. I be
Greetings!
Gabriel Dos Reis writes:
> Hi Camm,
>
> Camm Maguire writes:
>
> | Greetings!
> |
> | OK, I've committed an immediate fix to your compiler link problem. I
> | don't know how this ever worked on windows, but gcl needs to figure
> | out the init name for each lisp .o passed to compil
Greetings!
Gabriel Dos Reis writes:
> Camm Maguire writes:
>
> [...]
>
> | > Camm, do you think it is possible to make --disable-tk --disable-tcl
> | > entirely disabling linking with tcl/tk?
> | >
> |
> | OK --enable-tcltk is now a configure switch (default yes).
>
> Hi Camm,
>
> I just tried
Greetings!
Gabriel Dos Reis writes:
> On Fri, Aug 13, 2010 at 11:31 AM, Camm Maguire wrote:
>> Greetings!
>>
>> I've done a cvs update of open axiom, and I still have libtool
>> problems. I've checked in fixes to the gcl 2.6.8pre branch that
>> enables standalone compiler::link under mingw/win
Greetings!
Donald Winiecki writes:
> As Gaby reports, successful builds at my end, of CLTL1 and ANSI versions on
> WinXP and Vista.
>
> I haven't tested further, but will report back with ANSI tests and attempt
> builds of ACL2, Axiom and Maxima.
>
Thanks! BTW, has Control-C ever interrupte
On Fri, Aug 13, 2010 at 11:31 AM, Camm Maguire wrote:
> Greetings!
>
> I've done a cvs update of open axiom, and I still have libtool
> problems. I've checked in fixes to the gcl 2.6.8pre branch that
> enables standalone compiler::link under mingw/wine for me. I've also
> verified a maxima/gcl-a
Greetings!
I've done a cvs update of open axiom, and I still have libtool
problems. I've checked in fixes to the gcl 2.6.8pre branch that
enables standalone compiler::link under mingw/wine for me. I've also
verified a maxima/gcl-ansi/wine build.
I've extended the custom elf relocation facility
Hi, Camm --
Thanks. I don't mind missing a Debian release. If you become in more
of a rush, let me know.
You asked:
>> BTW, does SGC speed things up for you these days? I know how to
>> extend this to mac and windows, but have not done so yet.
I did a sort of modified ACL2 regression run on
Greetings!
Matt Kaufmann writes:
> Hi, Camm --
>
> Thanks for the fix! At one time, that same form (setq
> si::*multiply-stacks* 2), also failed on Windows. Does it work on
> Windows now?
>
Works for me under wine, so in all likelihood.
> I haven't forgotten to get you a fix for the issue o
1 - 100 of 1413 matches
Mail list logo
