GNU Common Lisp (gcl) - need a new security context?

[Gérard Milmeister]

Here are my findings:

(at home: Fedora-9 i386, gcl-cvs 20080908)
- SELinux is disabled
- using the bundled binutils instead of the system ones
  (configure --enable-locbfd --disable-statsysbfd)
- building everything with -O2 (-O3 is normally hardwired)
then GCL builds completely.

This also works in a local mock rawhide build.
However a scratch build using koji fails. I found that
there is a difference in the memory layout between local
(kernel 2.6.14) and koji (2.6.18) and GCL tries to do
some funny things (such as generating its own ld script)
which probably makes it fail ultimately. In particular
it tries to detect some memory layout parameters such
as stack ceiling (0xffffffff on koji, 0xbfffffff locally,
why is this?) and  "shared library/C stack ceiling to heap"
(sic) (herefore it looks at the last address used in
`ldd /usr/bin/awk`!!!).

Apropos SELinux:
When loading an image dump (made using unexec known from
emacs) GCL tries to change protection using mprotect.
It is possible to configure the garbage collector to omit
this step. Image loading then proceeds, but loading compiled
Lisp modules later fails again due to mprotect. There
is probably no way to circumvent this without making far
reaching modifications to GCL memory management itself.
Therefore creating a security context for GCL is probably
the only way to make GCL work smoothly in the mid-term
(provided we can get non-selinux builds to work).

This is as far as I have come currently, I hope that
together we may work out solutions.

Regards,
Gérard