[Ecls-list] Incompatible changes. CVS HEAD might be broken

[Juan Jose Garcia Ripoll]

Hi,

I wanted to warn everybody that I am conducting now important changes on the 
build process of ECL, and which have important side effects (see below). The 
goals are

* Restore the ability of ECL to garbage collect dynamically linked libraries 
that are not used. For instance if you do (COMPILE 'FOO '(LAMBDA (X)...)) and 
later on overwrite the definition of FOO, the compiled code should be 
unloaded and memory reclaimed.

* Use a different extension (.FAS) for compiled files. The reason for this is 
to avoid confusing dlopen(), which treats files with names lib*.so 
differently. It also makes a distinction between _modules_ (.FAS extension, 
can be loaded) and _libraries_ (.SO or .DLL extension, can be linked against 
ECL).

* Fix the way in which libraries are created to avoid security holes. Right 
now all I have figured out is including the --rpath flag when anything is 
linked against libecl.so. In a near future it may happen that the ECL library 
is installed in a more standard location.

* Ensure that ECL does not look for libraries in the ${prefix}/lib/ecl 
directory already during build time.

The current CVS tree includes fixes that attemp to solve all these problem. In 
particular, the first one is completely solved. However, users of CVS should 
be aware of the following.

1) I had to forbid the Boehm-Weiser garbage collector to scan the data segment 
of any DLLs. This means that people building shared libraries should either
	a) make sure that all data is pointed to either by lisp global variables
	b) store data in C variables which have been register_static_root()'ed
	c) set GC_no_dls = 0 and lose the ability to garbage collect code.

2) These fixes have been developed under linux-ix86 and have not been tested 
yet on other platforms. The sparc platform indeed produces a SIGSEG during 
build. I am stuck now on a piece of code that the GCC seems to miscompile. 
Help would be welcome.

3) The functions STATIC-LIBRARY-PATHNAME and SHARED-LIBRARY-PATHNAME 
disappear. Instead, the COMPILE-FILE-PATHNAME function now accepts a keyword 
argument, :TYPE, which can take the values, :DLL, :LIB, :C, :H, :O, :PROGRAM, 
:FASL. See the documentation for details.

Regards,

Juanjo

-- 
Max-Planck-Institut fuer Quantenoptik	+49/(0)89/32905-345
Hans-Kopfermann-Str. 1, D-85748		www.mpq.mpg.de/Theorygroup/CIRAC/
Garching b. Muenchen, Germany		Juan.Ripoll at mpq.mpg.de