Greetings! "Bill Page" <[EMAIL PROTECTED]> writes:
> On April 18, 2007 6:00 AM Waldek Hebisch wrote: > > > > Bill Page wrote: > > > Why not? It is not necessary to build gcl as part of the Axiom > > > build - just install the windows binary for gcl, like other > > > users Windows do. > > > > > > > Is there a binary version of gcl suitable for Axiom developement? > > The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are > > getting errors which vanish if we use 2.6.7 or 2.6.8. > > You are right and what I wrote above is wrong. Gaby also has > pointed out that it is not currently realistic to depend on the > GCL binaries on Windows for Axiom development. > > As far as I can tell no one has posted any binaries for GCL on > windows newer than > > gcl_2.6.6.mingw32_cltl1_japi_20050210.exe 22-Mar-2005 > > at > > http://ftp.gnu.org/gnu/gcl/binaries/stable > > And gcl-2.6.8pre is still a "pre-release". I guess the gcl > project is also critally lacking in resources. If it would be > helpful I could certainly upload a windows binary of this > pre-release to the Axiom Wiki web site. But I am discouraged > also by Gaby's observation that there does not seem to be much > interest in development of the Windows versions of GCL or > Axiom. :-( > Thanks so much for this update. GCL development, like most open source projects run by volunteers, usually proceeds in bursts, most frequently during the summer months. But I think it is also true, as we've discussed personally in the past, that the community dynamics of Windows computer users are by in large quite different from BSD/Linux users, in that relatively speaking there are far fewer people interested in actually contributing work than in simply downloading the work done by others. Mike Thomas was of course the heroic exception in this regard, and his determination of the superiority of the mingw environment vis a vis the cygwin environment coupled with his more than ample contributions of time and skill have given us the mingw system we have today. I do think we need to discuss the way forward, for unless we find his equivalent somewhere, it can be argued that it would be better for us to migrate to a system that can be well emulated and/or remotely accessed under Linux using familiar tools, even if those are deficient in other regards with respect to customary Windows usage. >From my own perspective, I feel most able to support (in descending order) Linux, BSD, Solaris, MacOSX, and lastly mingw, and alas it is likely to remain that way. We therefore are first in needs of a Windows porter, and next a MacOSX porter. I feel that GCL has also accumulated a certain degree of mingw experimental code which no one uses to my understanding and should be removed on conceptual grounds. I.e. japi and anything related to java, the separate windows main routines, and perhaps some alternative tk stuff if memory serves. I think we need to consolidate around unix concepts to the degree possible given our resources, and provide minimal well centralized emulations where required, e.g. sbrk. This means in all likelihood fork(), unix sockets, etc., which to my limited understanding point more in the direction of cygwin than mingw. (2.7.0 has parallel processing primitives based on fork. pargcl, an mpi extension, is also likely to be built by default in 2.7 and higher. This latter facility of course just requires a uniform external mpi interface which I hope we can avoid including with the gcl source as gmp and bfd are done now.) I don't think we should discontinue mingw so much as investigate a cygwin alternative which, if proven over time to be accessible within unix and adequate from the user's perspective, might eventually become the windows port of choice. This said, I will turn 180 degrees if anyone would like to step forward and fill Mike Thomas' shoes. Finally, I'm not even familiar with the windows package format concept, so if anyone would like a binary posted, we need a volunteer. I'd be quite happy to provide access to any qualified individual with interest. > > > > Also, can one install gcl without affecting existing Mingw > > installation (the gcl readme claims that on Windows gcl > > need a specific, rather old Mingw version -- for me > > downgrading Mingw is not an option)? > > > > MinGW is required in order to compile Lisp to object code and > of course to compile the Lisp output of the SPAD compiler in > Axiom. Unlike Linux, it is not correct to assume that a C > compiler is available in the basic window installation. The > existing binary installer that I prepared for Axiom on Windows > includes the necessary parts of MinGW to permit GCL and Axiom > to compile object code. I think a similar binary installer > for GCL should include these same parts of MinGW so that the > GCL installation will be complete and fully functional. > How big will this be? Who can tell me exactly what that means in terms of files shipped? Take care, > Regards, > Bill Page. > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "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
