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.
When mprotect is used as a cheap interrupt protection, the environment must be
page-aligned. For static data we'd need to use a kludge (or alignas that is not
part of C99) -- the simplest thing is to use the same mechanism to allocate the
first environment as the rest. That will ensure page alignment when mprotect is
used (that is, when mmap allocates the environment).
This was not possible before (in !341), because back then, when mmap was not
used, we've been using the garbage collector to allocate th environment, but now
we use the manual allocator.
Fixes#828.
When mprotect is used as a cheap interrupt protection, the environment must be
page-aligned. For static data we'd need to use a kludge (or alignas that is not
part of C99) -- the simplest thing is to use the same mechanism to allocate the
first environment as the rest. That will ensure page alignment when mprotect is
used (that is, when mmap allocates the environment).
This was not possible before (in !341), because back then, when mmap was not
used, we've been using the garbage collector to allocate th environment, but now
we use the manual allocator.
Fixes#828.
This compiler is:
- not fully conformant
- hard to obtain (despite free versions existing)
- requires numerous kludges
- requires separate build system so many changes need to be duplicated
Fixes#809.
Split up the options into additional flags for the linker and
additional libraries.
Quoting from issue #636:
> Here's an example, attempting to link one object file named
example.o into an executable named example. Libcrypto here is
superfluous and should be removed by --as-needed:
```
LDFLAGS="-Wl,--as-needed"
LIBS="-lcrypto"
gcc ${LDFLAGS} ${LIBS} example.o -o example # doesn't link libcrypto!
gcc example.o ${LDFLAGS} ${LIBS} -o example # doesn't honor --as-needed!
gcc ${LDFLAGS} example.o ${LIBS} -o example # works great!
```
> In short, the placement of your -l<foo> flags differs from that of
all the other linker flags. Since ECL is only providing one big
variable ld-flags for all of the linker flags, there's no correct
way to pass in options like --as-needed and -l<foo> at the same
time.
Fixes#636.
On Unix, pathnames are converted into the default encoding specified
by ext:*default-external-format* and back. On Windows, the operating
system already gives us utf16 encoded pathnames, so we use those.
ecl_namestring with ECL_NAMESTRING_FORCE_BASE_STRING encodes with the
specified encoding. Decoding is handled individually in the filesystem
functions.
Includes a minor refactor of list_directory, changing the
PARSE_DIRECTORY_ENTRY macro into an inline function.
Closes#609, #549.
Precompiled headers may not work in every scenario (for example
compilation currently fails for the --with-cxx=yes configure option
due to precompiled headers). If we disable them by default, we are on
the safe side.
Improves compilation speed for single functions by about 40-50
percent. Precompiled headers are specific to the compiler version and
options in use. Due to this, we regenerate the header whenever the
compiler configuration changes.
Announcement proposal. When this is merged to the develop branch, then
we should make a PR against master and merge. Then we shall publish
tarballs and the announcement on the website.
