[Top][All Lists]

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

RE: [Gcl-devel] GCL GPL/LGPL license

From: Mike Thomas
Subject: RE: [Gcl-devel] GCL GPL/LGPL license
Date: Thu, 8 Apr 2004 10:02:19 +1000

Hi Eric.

|   I am not so much interested in closed source apps
| and restrictive licenses as I am in having the options
| concerning the license I distribute under.
|  On a side note, is removing bfd and unexec a matter
| of  modifing the configs and makefile or more a matter
| of modifing the gcl source.

A bit of both - I've never tried removing UNEXEC myself.  There are two
areas of functionality involved:

AREA 1. If you remove BFD (o/sfaslbfd.c) you are removing the ability to
dynamically compile and link raw object files into a running lisp system (eg
loading foo.o, obtained by compiling foo.lsp) using the BFD library.  Having
said that, there are LGPL replacements in the "o" directory - Windows uses
it's own custom relocation code and the equivalent exists for elf systems
like Linux, however, I don't know how well that has been tested.  You can
also use a less functional dynamic library linking method.  These methods
are controlled by these configure switches (try configure --help to see for

 --enable-dlopen uses dlopen for loading objects, which can then not be
  in saved images

 --enable-statsysbfd uses a static sytem bfd library for loading and
ng object files

 --enable-dynsysbfd uses a dynamic shared sytem bfd library for loading and
cationing object files

 --enable-locbfd uses a static bfd library built from this source tree for
ng and relocationing object files

 --enable-custreloc uses custom gcl code if available for loading  and
ning object files

AREA 2. If you remove UNEXEC you remove the ability to dump a running lisp
system into a new executable (this method is used, for example, by both GCL
and the Maxima computer algebra system).  All is not lost as you can either
modify your build system to use ld to link up a bunch of object files to
make a new application executable, or you can use the lisp function

>(describe 'COMPILER::LINK)

COMPILER::LINK - internal symbol in COMPILER package


eg: (compiler::link nil "c:/foo") makes a new lisp executable called
c:/foo.exe on Windows using ld from the lisp prompt.

| Will gcl be broken by
| default without these libraries?

In the case of UNEXEC you will need to do some twiddling to remove it, I
don't know if anyone has actually tried yet, but I would expect it wouldn't
be too overwhelming.  It would probably be a good idea for us to put UNEXEC
switching into configure at some stage - I might register it as a feature
request in fact.

In closing, provided you can live with either of LGPL or GPL and provided
you can do the tweaking to build without UNEXEC and BFD if you want LGPL
then the flexibility is there for you.

Feel free to ask us if you need any further help with this stuff;  we
appreciate your interest.


Mike Thomas.

reply via email to

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