gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Support for dlopen fasloading


From: Camm Maguire
Subject: [Gcl-devel] Support for dlopen fasloading
Date: 25 Jul 2002 15:37:21 -0400

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.
2) an ansi lisp enthusiast (Vadim?) to check in the clocc tests, and
   write a few make rules to run them when building with
   --enable-ansi.
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

Wishlists:
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,
-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

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