[Gcl-devel] Re: binutils subtree removed

[Gabriel Dos Reis]

Camm Maguire <address@hidden> writes:

| Greetings!
| 
| Gabriel Dos Reis <address@hidden> 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.

agreed.

| I've removed the binutils subdir, as there are no machines now where
| it is needed.  

Fantastic!  This also means that GCL would benefit from newer linkers
such as Gold.

| 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.

OK.

| (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.)

A recent discussion I had with Ian Lance Taylor suggested that BFD is
something I should avoid, unless it is absolutely necessary.

| 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.

I agree.  This is an area we can and should revisit after 2.6.8 is
released. 

-- Gaby