[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Support for dlopen fasloading

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Support for dlopen fasloading
Date: Tue, 06 Aug 2002 23:00:25 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

Camm Maguire пишет:
Greetings!  I've just checked in what I hope to be a temporary
facility, but which should nevertheless extend maxima support to
all the Debian architectures.

If one chooses ./configure --enable-dlopen, both the bfd and the
traditional elf only relocation code is bypassed, and dlopen is used
to dynamically load .o files.  In such a configuration, the files will
need to be reloaded should the user choose to save her own lisp image
and then execute it.  This is in contrast to the other two cases, in
which saving an image effectively does a permanent link of all loaded
objects into the final executable.
This facility was previously used in the alpha-osf1 port, and in some
irix ports, apparently.  I just cleaned up a bit, and made this option
the default on the architectures where bfd relocations currently do
not work: mips(el), alpha, ia64, and hppa.  Hopefully there will be
time to submit patches to the binutils people, and incrementally
decrease this list to 0.

We need to think about the hierarchy of options.  My preliminary
thoughts on how this should go are typically found in linux.h.
Eventually, I hope to move these ifdefs to acconfig.h, and have
configure do all the work, with no hand-crafted arch-specific .h
files.  Suggestions here most welcome.

I hope to be able to post shortly a followup on our earlier roadmap,
detailing the progress thus far.  We may be getting close to a
release.  In any case, I want to release by the time maxima does.

Here are a list of jobs for some people who would like to help, but
don't like C:

1) a texinfo expert to compile the gcl.info files from their .texi
   sources, so we can include them in the distro.

Do you mean very gcl.info (gcl-tk.info and gcl-si.info seems to be OK)?
I mean gcl documentation which can be found at old gcl site as separate
archive. If yes I'll take a look on it.

2) an ansi lisp enthusiast (Vadim?) to check in the clocc tests, and
   write a few make rules to run them when building with

Presently result of ansi test from clocc is toooo verbose. I'll elaborate on it in a few days. I'm not quite sure how to treat some of
results obtained...  And it still stops abnormally at several points.

3) an organizationally minded person (Greg?) who can suggest patches
   to remove cruft from the source tree, develop a better source
   tree directory layout, and to consolidate and rationalize the
   configure process, paying careful attention to the logic implied in
   the options hierarchy.  Suggestions of Makefile.am's welcome too.

What I'm going to focus on:
4) standardizing the va_lists, and hopefully making all ansi compliant
5) clean out old macros
6) simplify headers
7) static functions where possible
8) search path problems with maxima cvs build
8.5) view -Wall C warnings from compilation of lisp source

9)  blas support
10) -lgcl to move bulk of lisp core into a shared lib.

Random thoughts:
11) Should we ship cmpinclude.h as gcl.h to be installed as part of
    the distro, as opposed to inlining the whole thing from a lisp
string? 12) Anyone know of a good C source integrity checker?

Take care,

     Vadim V. Zhytnikov


reply via email to

[Prev in Thread] Current Thread [Next in Thread]