Greetings! Gabriel Dos Reis <g...@cs.tamu.edu> 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, > `built on the fly as part of building AXIOM' without having to install it > permanently on the target system. > Indeed, I think the typical usage for distros is to maximize modularization, and for 'build it yourselfers', to maximize convenience. Its not a bad compromise to support both in many cases. And in the modern era, there are far fewer pure lisp enthusiasts than parties interested in a good CAS. I've removed the binutils subdir, as there are no machines now where it is needed. Native object location is ubiquitous save for the following linux systems, still using dlopen: ia64 hppa arm (thumb) (i.e. Ubuntu, not Debian) ppc64 (no known distro) Building with an external bfd library is still supported. The default configure option has been moved to custreloc. (To recap for those who might have missed earlier discussions, I had thought that bfd would eventually allow gcl to offload the difficult code relocation part in a portable manner. In following the development for many years, this never panned out. I've managed to implement what we need myself in a few weeks. Live and learn.) 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 illogical for its source to include this code somewhere. The older, no longer supported mp files are still present. But it is a separate project, and a hassle to keep current. My current suggestion is to leave it in at least for 2.6.8. Take care, -- 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