20d9266664
PROCLAIM-CLASS in ccmp had the following form in its body:
(ext:with-backend
:c/c++ (register-in-ccmp)
:bytecmp (register-globally))
with a clear intention, that CCMP-compiled code should use the first path, and
BCMP-compiled code should use the second. But that's not what this operator
does. This operator caused, that when CCMP was compiled with CCMP, then it
always took (register-in-ccmp) path (even for bytecodes compiler(!)), while when
CCMP was compiled with BCMP (i.e with a flag --disable-shared and compiler is
not builtin), then modifying global instance was always called, disregrading
whether we were compiling with CCMP or BCMP at the moment.
We've replaced this with a more precise statement that decides at runtime which
compiler to chose:
(if *compiler-in-use*
(register-in-ccmp)
(register-globally))
The other part of the problem was that registering the class definition globally
in the bytecodes compiler (or in ccmp when --disable-shared was true), could
redefine existing class in runtime environment with a forward-referenced-class,
and that lead to the environment corruption. Consider:
(compile-file "foo.lisp" :load t) ;defines globally at load time "#<standard-class foo>"
(compile-file "foo.lisp" :load nil) ;defines globally at compile time "#<forward-class foo>"
So after compiling the second file, we don't have the standard class foo, that
we may depend on in later files.
Fixes #843.
|
||
|---|---|---|
| contrib | ||
| examples | ||
| msvc | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| appveyor.yml | ||
| CHANGELOG | ||
| configure | ||
| COPYING | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.in | ||
| README.md | ||
ECL stands for Embeddable Common-Lisp. The ECL project aims to produce an implementation of the Common-Lisp language which complies to the ANSI X3J13 definition of the language.
The term embeddable refers to the fact that ECL includes a Lisp to C compiler, which produces libraries (static or dynamic) that can be called from C programs. Furthermore, ECL can produce standalone executables from Lisp code and can itself be linked to your programs as a shared library. It also features an interpreter for situations when a C compiler isn't available.
ECL supports the operating systems Linux, FreeBSD, NetBSD, DragonFly BSD, OpenBSD, Solaris (at least v. 9), Microsoft Windows (MSVC, MinGW and Cygwin) and OSX, running on top of the Intel, Sparc, Alpha, ARM and PowerPC processors. Porting to other architectures should be rather easy.