gmane.lisp.gcl.devel

up-to-date setup instructions for Win32 GCL

Donald Winiecki — 2012-05-25T18:53:44

Hi,

It's about a year late but included below is the most up-to-date setup
directions for Win32 GCL.  This includes setting up and using a CVS client,
and building Win32 GCL on a current WinXP, WinVista and Win7.

Next it's the regular docs.

Best,

_don



===============================================
BUILDING NATIVE WIN32 GNU COMMON LISP FROM CVS
===============================================

The preferred build host system for the Mingw32 compiler is MSYS.

I use gcc version 3.3.1 and binutils 2.14.90, but earlier versions
of gcc back to 2.95 are OK provided that you remove the
"-fno-zero-initialized-in-bss" flag in "h/mingw.defs" before running
"configure".

Note that gcc 3.3.3 and gcc 3.4.0 do NOT work; likewise binutils 2.13.90
and 2.15.90.

The working binutils version can be found at:

http://gd.tuwien.ac.at/gnu/mingw/binutils-2.14.90-20030612-1.tar.gz

===============================================
INSTALL AND CONFIGURE TORTOISE CVS
===============================================

Download Tor

Compiler does not give error if T clause in case construct is not last one

Faheem Mitha — 2012-03-22T20:54:43

Hi,

The bugs page at http://savannah.gnu.org/bugs/?group=gcl looks dead, so I'm 
writing to the developer mailing list. If there is a more suitable place to 
report bugs, let me know and I'll send it there.

Consider the following session. I believe this is wrong.

faheem< at >orwell:/usr/bin$ gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    Jan 20 2012 20:04:53
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/


X

)

FOO


"matches t"
"matches t"

See also https://bugs.launchpad.net/sbcl/+bug/959687 for context.

Please CC me on any reply. Thanks.

                                                  Regards, Faheem

the allocate function

2011-12-09T07:05:59

I was using maxima and got an error like this (then I referred to gcl 
documentation):

[

Maxima encountered a Lisp error:

Error in PROGN [or a callee]: The storage for CONS is exhausted.
Currently, 43968 pages are allocated.
Use ALLOCATE to expand the space.

]//end of error

The maxima texinfo manual says to refer to the gcl documentation regarding 
ALLOCATE or GBC.  However, when I look up ALLOCATE in the gcl texinfo 
manual, it doesn't really give the usage details (for allowable "types"), 
and furthermore when I type (ALLOCATE CONS 50000) in gcl, I get an error 
saying "the variable CONS is unbound".  I'm using gcl 2.6.7-62, and 
gcl-doc (same version) in Debian stable, and the maxima version I'm using 
is 5.21.1-2squeeze (in Debian stable).

Thanks and regards,
Rory

Invitación a conectarnos en LinkedIn

Jose Antonio Garcia Peiro — 2011-09-20T12:58:57

Me gustaría añadirte a mi red profesional en LinkedIn.
 
-Jose Antonio

Jose Antonio Garcia Peiro
Estudiante de Universidad Miguel Hernández de Elche
Murcia Area, Spain

Confirm that you know Jose Antonio Garcia Peiro:
https://www.linkedin.com/e/59rl43-gssw4eqc-4d/isd/4281115163/Dx6M74Gc/?hs=false&tok=3nb13UwAkGPQU1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/59rl43-gssw4eqc-4d/osJ5VdODPIZ7VVwDokqKZOnBB3wN/goo/gcl-devel%40gnu%2Eorg/20061/I1480878321_1/?hs=false&tok=1bO5Zv4p0GPQU1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
_______________________________________________
Gcl-devel mailing list
Gcl-devel< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gcl-devel

Building GCL on Windows7

Donald Winiecki — 2011-08-18T18:26:41

I've just configured a Windows7 machine and confirmed that setting up
build tools to compile GCL on Win7 should be done following the
published directions for WinVista.

(In fact, as some who have followed previous discussions on this list
know, building GCL on an updated WinXP machine requires that one
follow the published directions for Vista rather than XP -- this owing
to what we can call the `Vistafication' of WinXP as patches are
installed.)

I'll be updating the directions soon and can make those available to the group.

Best,

_don

Build fixes for 32 bit Ubuntu Linux 11.04

Blake McBride — 2011-07-05T21:40:42

Greetings,

The following changes were necessary to get GCL to build on the above
mentioned machine.  The first error is new for me.  The second one has
been an issue for years.  After these changes everything built and ran
fine.

1.  Fix configuration failure due to unexpected path for ld:

--- configure~2011-07-05 14:09:46.000000000 -0500
+++ configure2011-07-05 15:53:05.553382999 -0500
< at >< at > -8120,7 +8120,7 < at >< at >
    heap_ceiling=0x0
 else
 if test -d /proc/self ; then
-   heap_ceiling=0x`/bin/cat /proc/self/maps | grep "/lib/ld" | cut
-f1 -d- | head -1`
+   heap_ceiling=0x`/bin/cat /proc/self/maps | grep "/lib.*/ld" | cut
-f1 -d- | head -1`
 else
 #echo -e "#include <stdio.h>\n int main() {printf(\"foo\");return 0;}" >foo.c
 #$CC foo.c -o foo


2.  After running configure modify makedefs as follows:  (This has
been a problem for years.)

--- makedefs~2011-07-05 15:54:41.401036915 -0500
+++ makedefs2011-07-05 15:57:59.727036589 -0500
< at >< at > -46,9 +46,9 < at >< at >

 NOTIFY=yes
 CC=gcc
-CFLAGS=  -fsigned-char -pipe -Wall

-Wno-unused-but-set-variable

Gabriel Dos Reis — 2011-06-15T04:21:43

Hi Camm,

The option -Wno-unused-but-set-variable is a relatively new option in GCC.
For example, on the system compiler provided by SLE-11-SP1, GCC aborts
on unrecognized options; therefore GCL-2.6.8pre builds fails there.

I would suggest that the inclusion of that switch in CFLAGS be
controlled by a configure-time test.

(no subject)

Camm Maguire — 2011-04-07T14:25:40

test

notinline functions lose secondary values

Faré — 2011-03-31T17:11:25

Reduced test case. Using GCL 2.7.0 in ANSI mode.

(load (compile "bug.lisp"))

;;; bug.lisp contents follow:

(in-package :cl-user)

(defun bar (x)
  (values x x))
(declaim (notinline bar))
(defun foo (x)
  (multiple-value-bind (a b) (bar x)
    (list a b)))
(format t "~&~S~%" (foo 1)) ;==> (1 NIL) instead of (1 1)

(defun baz (x)
  (values x x))
(declaim (inline baz))
(defun quux (x)
  (multiple-value-bind (a b) (baz x)
    (list a b)))
(format t "~&~S~%" (quux 1)) ;==> (1 1) as expected

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
When you've seen one nuclear war, you've seen them all.

Successful build of gcl269pre-ANSI on WinXP(32) -- how I was ultimately successful, BUT problems with info files in REPL

Donald Winiecki — 2011-03-22T17:42:59

Hi all!

Over the past several weeks I have been working to create a native
WinXP (32 bit) build of the current gcl268pre.  Up until last night I
had been unsuccessful on four separate machines running WinXP either
natively or under emulation (through Sun's/Oracle's VirtualBox).
Building the CLtL1 variant had never been a problem.

I was finally successful after installing the build tools following my
directions for preparing to build GCL on WinVista.  I have tried and
had success on three of the four machines that previously failed a
gcl268pre-ANSI build (I haven't yet tried on the fourth machine).

Paranoid as I am, I normally keep all Windows operating systems up to
date with patches from Microsoft and right now I'm guessing (and it's
just that, a guess) that some recent patches from Microsoft for WinXP
have put code or operating characteristics from WinVista into WinXP.
This may (hypothetically) account for my inability to build
gcl268pre-ANSI natively on an up-to-date installation of WinXP.

But even wi

continued inability to make ANSI gcl260pre on WinXP

Donald Winiecki — 2011-03-21T23:27:26

Hi all,

Over four separate machines using WinXP (32bit) SP3, I have had
absolutely no success in building the ANSI variant.  CLTL1 presents no
problem whatsoever but ANSI blows up every time during make.

Included below is the last bit of the make.log that seems to point at
the important issue (the whole make.log is posted at the following
URL: http://coen.boisestate.edu/dwiniecki/GCL/make-failure-WinXP-gcl268pre.txt.log).

I see no way that four separate machines could all have memory
problems leading to this...

;; Note: Tail-recursive call of CLASS-FROM-TYPE was replaced by iteration.
;; Note: Tail-recursive call of DO-COLUMN was replaced by iteration.
End of Pass 2.
OPTIMIZE levels: Safety=1 (No runtime error checking), Space=0, Speed=3
Finished compiling c:/_cvs/gcl/unixport/../pcl/gcl_pcl_methods.o.
Loading binary of GCL_PCL_METHODS...
Compiling GCL_PCL_FIXUP...
Compiling c:/_cvs/gcl/unixport/../pcl/gcl_pcl_fixup.lisp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=1 (No runtime error checking)

Legacy code won't run in gcl-2.7_7

phones head — 2011-03-03T18:40:05

Hi, I've got source code allerged to work well in gcl-2.3, but when I
tried to run it in gcl-2.7_7, it raised many error, among them are
UNDEFINED PACKAGE, and export symbol conflict. I tried to fix them by
add (defpackage "XXX") before (in-package "XXX") and shadow some
symbols against others. But many wierd error just keep comes, I don't
even know what the error is. Could anyone help me out?
Best wishes!

GCL268pre (still) fails in ANSI build on WinXP (on newmachine)

Donald Winiecki — 2011-03-01T18:12:08

Hi all,

In my attempts to address build issues on my principal WinXP machine, I've
finally gotten access to another WinXP machine (amazing how hard it is to
convince people to give access to machines they don't use anymore!).

But building the ANSI variant still fails in a most ugly way.  This appears
to be a different problem than experienced on my main WinXP machine.

The full log can be seen at the following URL:

http://coen.boisestate.edu/dwiniecki/GCL/make-failure-WinXP-gcl268pre.txt

As before, the CLtL1 variant builds without drama.

Best,

_don winiecki
_______________________________________________
Gcl-devel mailing list
Gcl-devel< at >gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel

Patch for gcc 4.6 / volatile

Jerry James — 2011-02-11T04:21:04

The Fedora project is in the midst of a mass package rebuild.  One of
the reasons for doing this is so that all C/C++/... code in Fedora 15
packages will have been built with GCC 4.6 (to be).  The GCL package
failed to rebuild.  The build failure looks exactly like the one
reported here, but this time GCC did emit warnings:

http://lists.gnu.org/archive/html/gcl-devel/2005-07/msg00028.html

I think the "volatile" annotations are still not correct.  The
attached patch results in a successful build for me.  I think the
print.d portion is obviously correct.  For the prog.c portion, the
pointers in new_top and bodysv are used after the setjmp call, so
should also be volatile.  The tinf variable is only used to iterate,
and is initialized after the setjmp call, so it does not need to be
volatile.  The tinf_base variable (as also new_top and bodysv) should
be declared with the "volatile" AFTER the asterisk, rather than
before, because it is the pointer itself that needs to survive the
setjmp call, not the thing po

identifying string-streams

Matt Kaufmann — 2011-01-23T17:58:16

Hi --

I'd be grateful if someone can answer the question below, even in the
negative, but I can work around the issue so please don't spend more
than a moment on this.

In ANSI Common Lisp, (typep stream 'string-stream) is true when stream
is connected to a stream (hence not to a file).  In non-ANSI GCL, the
type of such a stream is 'stream, not 'string-stream, and the only way
I found (after considerable searching) to do such a query is as
follows:

(si::stream-name stream) appears to return NIL if and only if stream
is a string-stream.

QUESTION: For non-ANSI GCL, is this correct for both past and future
versions, or is there a better way to identify string-streams?

Thanks.  If there is a different list I should query instead, please
let me know (and, my apologies).

Regards,
Matt Kaufmann

Man page problems (2.6.8)

Jerry James — 2011-01-02T00:55:44

While reading the gcl man page, I noticed some oddities.  The first one is
because of this construct on lines 149-154:

.B \-compile
.RB
Invoke the compiler on the filename following
.BR \-compile
.  Other
flags affect compilation.

The ".  Other" is interpreted as a macro, due to a "." at the start of the
line.  Since nroff doesn't recognize the macro, it drops the entire line
from the output.  The second is in lines 206-209:

This GNU package should not be confused with the proprietary program
distributed by FRANZ, Inc.
Nor should it be confused with the public domain \*(Fl or the proprietary
\*(Li.

What are "\*(Fl" and "\*(Li" supposed to be, lists of free and proprietary
Lisps, respectively?  If so, what is supposed to generate those lists?

For the time being, I'm applying the following patch to the Fedora gcl
build.  Please let me know if there's a better solution.

--- man/man1/gcl.1.orig    2002-02-03 11:44:07.000000000 -0700
+++ man/man1/gcl.1    2010-12-30 14:09:50.834355544 -0700
< at >< at > -149,8 +149,7

Building GCL on Win32 -- ANSI variant still fails on myrebuilt WinXP machine...

Donald Winiecki — 2010-12-25T16:21:46

Camm,

After my WinXP machine died, you took up the task of verifying that
GCL268pre could build on that platform.

With the end of the semester I reconfigured the dead machine with
Ubuntu 10.10 and installed WinXP under emulation through Sun's (now
Oracle's) VirtualBox.

I can successfully build the CLtL1 version of GCL, but the ANSI
version fails at make.  Did you have success building the ANSI version
in your trials?  (Building both variants on my WinVista machines is
still unproblematic.)

I'll send the logs for configure and make to your home E-mail since
they seem to be too big to fit into the GCL-devel list.  I can send
them to anyone else interested also -- just let me know.

Best wishes for the season and new year!

_don

~~~~~~~~~~~~~~~~~~~~~~~~~
Don Winiecki, Ed.D., Ph.D.
Professor
Boise State University, College of Engineering
Department of Instructional & Performance Technology
1910 University Drive, Boise, Idaho 83725-2070 USA
E-mail: dwiniecki< at >boisestate.edu
WWW: http://ipt.boisestate.edu
Tele

message for Camm

Matt Kaufmann — 2010-11-26T19:21:01

Hi, Camm --

I just replied to an email you sent me from camm< at >maguirefamily.org,
but got this bounce message:

   ----- The following addresses had permanent fatal errors -----
<camm< at >maguirefamily.org>
    (reason: 503 This mail server requires authentication when attempting to send to a non-local e-mail address. ...tings or contact your administrator to verify that the domain or address is defined for this server.)

Is there a new way for people to contact you other than via
gcl-devel< at >gnu.org?

Thanks --

ASDF 2.010.5

Faré — 2010-11-18T18:05:47

Dear GCL developers,

in the latest ASDF 2.010.5 (successor to the previously mentionned 2.147),
GCL support is mostly working.

Could you do the following?

1) include ASDF in GCL so that (require :asdf) works

2) hopefully, fix the issue with define-condition?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Our system is defined to prevent majority politicians from overtly oppressing
minorities. However, our system is also overtly defined to let majorities
elect majority politicians and not let minorities wield electoral power.
Kinda funny... one part of our constitution tries to fix a problem which
the other half of the constitution tries to create!
— Lee Salzman <eihrul< at >tunes.org>, about the US political system.

mingw32 paths

Camm Maguire — 2010-10-29T16:26:10

Greetings!  I've successfully tested maxima and acl2 under both wine
and a native windows machine.

I have a question regarding paths.  From what I can tell, gcl needs
*to be run* under a mingw32 shell if it wants to compile anything.
Said shell reports paths as /c/dir/foo.c, but GCL's current truename
and probe-file expect c:/dir/foo.c.  What is 'supposed to happen'
here?  

Take care,

ASDF 2.147

Faré — 2010-10-29T13:56:51

Dear GCL developers,

I just released ASDF 2.010 but unhappily, it's broken on GCL.

However, ASDF 2.147 fixes the most glaring issues: adding a defpackage
that GCL craves, and correctly working around a bug whereby GCL fails
to put :relative at the head of the pathname-directory of a relative
pathname.

Now, GCL also borks when I try to handle conditions, with such errors as:
Condition in IF [or a callee]: INTERNAL-SIMPLE-TYPE-ERROR:
CONDITIONS::INTERNAL-SIMPLE-MISSING-DEPEN
DENCY-OF-VERSION is not of type (SATISFIES
CONDITIONS::CONDITION-CLASS-P): Not a condition type: CONDITIONS::I
NTERNAL-SIMPLE-MISSING-DEPENDENCY-OF-VERSIONABORTING:
 #<CONDITIONS::INTERNAL-SIMPLE-TYPE-ERROR.0>

Looks like the condition system fails to make something a subclass of
CONDITION-CLASS then complains about it.
Note also the annoying missing newline between the condition and ABORTING:

I hope this is an artefact of my using debian's antiquated
GCL (GNU Common Lisp)  2.7.0 ANSI    May  7 2010 22:44:41
and that these bugs have be